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RESUMO 


Apesar das novas e efetivas técnicas de engenharia de software, os projetos de 
desenvolvimento de sistemas estào propensos a ter os mesmos problemas que 
acometem o software de apoio à gestào. Entrega corri atraso, acima do ornamento e 
nào suprindo as reais necessidades dos usuàrios finais ou da organizagào que està 
financiando o desenvolvimento do sistema, sào os principais problemas. Esse ùltimo 
problema é o que mais afeta o desenvolvimento de sistemas e é um desafio para 
que o desenvolvimento personalizado seja urna solugào reai para vàrias empresas. 
Este trabalho apresenta urna proposta de mètodo de gestào que auxilie a 
comunicagào entre as atividades associadas à engenharia de requisitos e as 
atividades associadas à modelagem dos processos de negócio. Essa abordagem 
concerne à gestào e tratamento de requisitos de sistemas baseando-se em técnicas 
de engenharia de processos de negócios e de engenharia de requisitos, no processo 
unificado de desenvolvimento de software e na utilizagào de linguagens semi-formais 
e formais de modelagem, UML e SysML respectivamente. O mètodo pretende 
mitigar os efeitos dos problemas de comunicagào existentes entre os diversos 
integrantes de um projeto, com especial atengào para a comunicagào entre a equipe 
de requisitos do projeto e os stakeholders responsàveis pela aceitagào e aprovagào 
do sistema. A pesquisa, com o apoio da apresentagào de dois casos que ilustram o 
mètodo de gestào proposto, permite concluir que é possivel tornar mais efetiva e 
produtiva a comunicagào entre os diversos envolvidos com o projeto, podendo 
resultar em um processo mais eficiente para a aceitagào dos requisitos junto aos 
stakeholders. 

Palavras-chave: Engenharia de Requisitos. Modelagem de Negócio. Linguagens 
Formais. UML. SysML. 



ABSTRACT 


Despite new and effective software engineering techniques, System development 
projects are likely to have thè same problems that affect thè management support 
software. Delivery delay, above budget and not fitting thè reai needs of end users or 
thè organization that is funding thè System development, are thè most common 
problems. The latter problem is thè one that most affects thè systems development 
and is a challenge for thè custom development to be a reai solution to several 
companies. This work presents a proposai for a management method to help thè 
communication between thè activities associated with thè engineering requirements 
and thè activities associated with business processes modeling. This approach, 
concerns to thè systems requirements treatment and management, is based on 
business processes engineering and requirements engineering, in software 
development unified process and in thè use of semi-formal and formai modeling 
languages as UML and SysML, respectively. The method seeks to mitigate thè 
effects of thè communication problems among thè project members, with special 
attention to thè communication between thè project requirements team and thè 
stakeholders responsible for thè System acceptance and adoption. The research, 
supported by thè presentation of two cases which illustrates thè proposed 
management method, has concluded that it is possible to make more effective and 
productive communication among members related with thè project, which may result 
a more efficient process for thè stakeholders requirement acceptance. 


Keywords: Requirements Engineering. Business Modeling. Formai Languages. UML. 
SysML. 
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1 INTRODUQÀO 


Segundo Booch et al (1999), urna organizagào bem sucedida no 
desenvolvimento de sistemas é aquela que consegue obter produtos de qualidade 
que casam com as necessidades de seus usuàrios de forma adequada e previsivel, 
através da utilizagào efetiva e eficiente dos seus recursos humanos e materiais. 

O desenvolvimento de sistemas requer a participagào de pessoas com os mais 
diversos perfis e expectativas quanto aos resultados obtidos, oferecendo 
instrumentos eficientes de comunicagào entre estas pessoas visando ao 
entendimento adequado de suas expectativas. O usuàrio final espera um sistema 
que atenda as suas necessidades diàrias e facilite o seu trabalho; os financiadores 
do sistema esperam um sistema que oferega o retorno adequado a seu 
investimento; e a equipe de desenvolvimento espera desenvolver um sistema de 
qualidade, no prazo e custo estipulado e atendendo as reais necessidades dos 
usuàrios (Leffingwell & Widrig, 2000). 

Apesar das novas e efetivas técnicas de engenharia, os projetos de 
desenvolvimento de sistemas estào propensos a falhar e frequentemente sistemas 
complexos sào entregues com atraso, acima do ornamento e nào atendem as reais 
necessidades dos usuàrios finais ou da organizagào que està financiando o sistema 
(Kotonya & Sommerville, 1998). 

Segundo Procaccino et al (2002), estudos realizados em empresas americanas 
indicaram que cerca de 20% dos projetos de desenvolvimento de sistemas 
fracassaram e ainda segundo Molokken & Jorgensen (2003) a maioria dos projetos 
de software, entre 60 e 80%, foram executados com atraso ou ornamento excedido. 
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No processo de desenvolvimento de sistemas é geralmente das etapas iniciais 
que decorrem a maior parte dos problemas. Paradoxalmente as etapas iniciais sào 
as menos dispendiosas por nào exigirem grande aquisigào de bens e servigos. 
Porém, sào as de maior impacto negativo quando realizadas de forma inadequada. 
Estas etapas constituem o processo de engenharia de requisitos, que tem sido 
reconhecida corno urna das mais importantes fases do processo de engenharia de 
sistemas (Kotonya & Sommerville, 1998). 

Os processos associados à engenharia de requisitos sào os responsàveis 
pelas evidèncias mais comuns e sérias de problemas, sendo 12% destes problemas 
associados a mudangas nos requisitos e especificagòes, 12% associados a 
requisitos e especificagòes incompletos e 13% associados à falta de engajamento 
do usuàrio (Leffingwell & Widrig, 2000). 

O custo para reparar um problema no desenvolvimento de sistemas aumenta 
significativamente quando este é descoberto nas etapas mais avangadas do ciclo de 
vida do desenvolvimento. O custo para tratar um problema detectado quando o 
sistema està em produgào é 500 vezes maior do que se fosse detectado e tratado 
na fase de requisitos (Carr, 2000). 

De acordo com Kotonya & Sommerville (1998), a atividade final da engenharia 
de requisitos é a validagào de requisitos que objetiva estabelecè-los de forma 
cometa, consistente, integra e precisa. A validagào de requisitos é um processo 
longo, envolvendo um grupo heterogèneo de pessoas que estào tratando um 
extenso e complexo documento, envolvendo a participagào dos stakeholders 1 , dos 
engenheiros de requisitos e da equipe de design, através da anàlise dos requisitos 

1 Stakeholders sào as pessoas ou organizagòes que serio afetadas pelo sistema e que influenciam 
de forma direta ou indireta os requisitos do sistema (Kotonya & Sommerville, 1998). 
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documentados, buscando problemas, omissóes e ambiguidades. O principal 
problema na validagào dos requisitos é a inexistència de urna referència 
documentada para ser utilizada corno base na validagào do documento de 
requisitos. (Kotonya & Sommerville, 1998). 

A utilizagào dos processos de negócio corno referència documentada pode 
oferecer urna base de aderència para a validagào e aceitagào dos requisitos do 
sistema, fornecendo elementos para a busca de um mètodo de gestào de requisitos 
capaz de catalisar, de forma eficiente, a complexa e exaustiva atividade de validagào 
e aceitagào dos requisitos junto aos usuàrios e stakeholders envolvidos com o 
sistema. A adogào de urna linguagem de modelagem formai, precisa e padronizada 
pode oferecer a este mètodo de gestào de requisitos a eliminagào de possiveis 
ambiguidades e imprecisòes nos modelos, podendo ser utilizada pelas diversas 
equipes do projeto, oferecendo um canal bàsico e consistente para a comunicagào 
interna e externa do projeto. 

1.1 OBJETIVOS 

O objetivo deste trabalho è propor um mètodo de gestào que auxilie a 
comunicagào, durante as etapas de definigào dos requisitos de um sistema, entre a 
equipe de engenharia de requisitos e a equipe de engenharia de processos de 
negócio, através de urna maior aderència entre os requisitos do sistema e o modelo 
de negócio da organizagào. 

Especificamente o trabalho se propóe a: 

• Apresentar os fundamentos teóricos da Engenharia de Processos de Negócio e 
da Engenharia de Requisitos, de modo a identificar os pontos criticos 
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relevantes para a aderència entre a modelagem dos processos de negócio e 
a eliciagào e especificagào dos requisitos. 

• Propor um mètodo de gestào de requisitos sustentado pela aderència com os 

processos de negócio da empresa, que na fase de eliciagào e aceitaqào dos 
requisitos do sistema, auxilie a comunicagào com os stakeholders. 

• Buscar urna linguagem formai de especificagào de requisitos que permita a 

gestào dos requisitos aderente aos processos de negócio. 

1.2 JUSTIFICATIVA 

Considerando-se que: 

• A engenharia de sistemas possui um enfoque interdisciplinar que viabiliza a 

realizagào com èxito de sistemas através da definigào antecipada das 
necessidades e funcionalidades requeridas, da documentagào dos requisitos, 
da sintese do design, da validagào do sistema e da consideralo do 
problema corno um todo (INCOSE, 2007). 

• A modelagem de sistemas é um elemento importante do processo de 

engenharia de sistemas, pois oferece, aos diversos envolvidos no negócio, 
urna abstragào capaz de facilitar o entendimento de processos complexos de 
negócio, oferecendo instrumentos que viabilizem a busca e obtengào de 
melhorias e inovagàes (Noran, 2000). 

• A complexidade dos processos de negócio das organizagóes implica a 

utilizalo de estruturas e modelos adequados para a gestào dos processos 
de negócio e que as necessidades impostas por estes processos de negócio 
devem direcionar as especificagàes dos sistemas nas empresas (Marshall, 
2000 ). 
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• A melhoria da comunicagào entre os diversos integrantes de um projeto, 
principalmente entre as equipes de especificagào de requisitos, modelagem 
de negócio e os stakeholders responsàveis pela aceitagào e aprovagào dos 
requisitos do sistema, pode resultar em melhoras acentuadas na qualidade 
dos artefatos gerados nas etapas de especificagào de requisitos. 

Tem-se que a proposta do mètodo de gestào de requisitos, aderente a 
modelagem de negócio da empresa e utilizando linguagem formai de modelagem e 
especificagào, além de ser inovadora dentro da literatura cientifica da engenharia de 
requisitos e da engenharia de processos de negócio, pode alterar a forma corno as 
equipes de trabalho abordam e registram, tanto a especificagào dos requisitos corno 
a modelagem de negócio, oferecendo urna possivel redugào de custo e tempo, 
principalmente nas fases de validagào e aceitagào dos requisitos, e urna possivel 
melhora na aderència entre o sistema final e as reais necessidades das empresas e 
dos stakeholders, aumentando assim as expectativas de sucesso nos projetos de 
desenvolvimento de sistemas. 

1 .3 ORGANIZAQÀO DO TRABALHO 

Considerando o objetivo deste trabalho e as principais questòes a serem 
estudas para atender este objetivo, foi proposta urna pesquisa aplicada, pois objetiva 
gerar conhecimentos para aplicagào pràtica e dirigidos à solugào de problemas 
especificos, envolvendo verdades e interesses locais. Além disso, este estudo busca 
urna melhor compreensào do foco abordado pela motivagào, podendo ser 
classificada corno sendo exploratória com relagào aos seus objetivos, pois visa a 
proporcionar maior familiaridade com o problema, visando a tornà-lo explicito e 
finalmente, pesquisa qualitativa, pois considera que nem tudo pode ser quantificado 
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e traduzido em numeros, onde a interpretagào dos fenómenos e a atribuigào de 
significados sào elementos bàsicos e que existe urna relagào subjetiva e dinàmica 
entre o mundo reai e o objeto de estudo. 

No capitulo 2 é feita urna revisào da literatura, apresentando conceitos das 
diversas abordagens voltadas à modelagem de processos do negócio, à engenharia 
de requisitos, ao desenvolvimento de sistemas de informagào e à utilizagào de 
linguagens formais e semi-formais destinadas à especificagào de sistemas. 

O capitulo 3 apresenta à proposta de um mètodo para gestào de requisitos, 
aderente ao modelo de processos de negócio e utilizando linguagens formais para a 
representagào dos requisitos. 

O capitulo 4 é dedicado a urna ilustragào do mètodo proposto através de dois 
estudos de caso: o primeiro associado ao desenvolvimento de sistemas de 
informagào e o segundo associado ao desenvolvimento de um sistema de 
supervisào e controle de màquinas de venda. 

No capitulo 5 sào discutidos os pontos relevantes sobre o mètodo de gestào 
proposto e sua aplicagào pràtica aos casos. 

E, finalmente, as conclusòes a respeito do estudo desenvolvido e possiveis 
encaminhamentos para trabalhos futures sào tratados no capitulo 6. 



21 


2 REVISÀO DA LITERATURA 

Considerando o objetivo deste traballio que é desenvolver um mètodo de 
gestào que auxilie a comunicagào entre as atividades associadas à engenharia de 
requisitos e as atividades associadas ao levantamento de processos de negócio, o 
foco deste capitulo é apresentar um panorama sobre a pesquisa desenvolvida, mais 
especificamente através da abordagem dos seguintes itens: 

• Apresentar conceitos bàsicos associados à engenharia de sistemas, 
originària da engenharia de processos de negócio e da engenharia de 
requisitos. 

• Abordar a engenharia de processos de negócio buscando destacar a 
importància destes processos para as organizagòes, a diversidade de 
técnicas e métodos de tratamento e representagào, com ènfase na 
utilizagào de UML para modelagem de negócio. 

• Evidenciar a importància do processo unificado de desenvolvimento de 
software, que contempla desde as atividades de modelagem de negócio 
até as atividades de teste e impiantalo. 

• Introduzir o conceito de engenharia de requisitos e sua importància 
dentro do processo de desenvolvimento de sistemas, descrever as 
etapas do processo de engenharia de requisitos e destacar a 
importància da eliciagào, validagào e gestào dos requisitos. 

• Introduzir os conceitos associados à linguagem formai SysML, estendida 
da UML 2 e criada para ser urna linguagem unificada de modelagem de 


sistemas. 
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2.1 ENGENHARIA DE SISTEMAS 


A engenharia de sistemas focaliza os diversos elementos que compóem um 
negócio, analisando-os, projetando-os e organizando-os em um sistema que pode 
ser um produto, um servigo ou urna tecnologia para a transformagào da informagào 
(Pressman, 2006). 

De acordo com o INCOSE, International Council on Engineering Systems, a 

engenharia de sistemas pode ser definida corno: 

“[...] enfoque interdisciplinar que viabiliza a realizagào com èxito de 
sistemas. Possui foco na definigào antecipada, dentro do ciclo de 
desenvolvimento, das necessidades dos clientes e das funcionalidades 
requeridas, documentando os requisitos, para entào passar a fase de 
sintese do design e validagào do sistema, considerando o problema corno 
um todo. A Engenharia de Sistemas integra todas as disciplinas e grupos 
especializados em urna unica equipe, criando um processo estruturado para 
o desenvolvimento que passa da concepgào, para a produgào e depois para 
a operagào. A Engenharia de Sistemas considera tanto as necessidades de 
negócio, corno as necessidades técnicas de todos os clientes com o objetivo 
de fornecer um produto de qualidade atendendo as necessidades do 
usuàrio.” (INCOSE, 2007) 


A engenharia de sistemas toma diferentes formas dependendo do dominio da 
aplicagào. Quando o contexto do trabalho de engenharia focaliza urna empresa de 
negócios, tem-se a engenharia de processo de negócio. Quando o contexto é a 
construgào de um produto, tem-se o processo de engenharia de produto. Em ambos 
os contexto no qual o sistema reside, este deve ser entendido e urna representagào 
efetiva produzida (Pressman, 2006). 

A modelagem de sistemas é um elemento importante do processo de 
engenharia de sistemas, independente da visào considerada, pois oferece, aos 
diversos envolvidos no negócio, urna abstragào capaz de facilitar o entendimento de 
processos complexos de negócio, oferecendo instrumentos que viabilizem a busca e 
obtengào de melhorias e inovagóes (Noran, 2000). 
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Um modelo é urna simplificagào da realidade, constando para melhorar o 
entendimento do sistema ou negócio. O processo de modelagem permite o 
refinamento sucessivo da representagào de um problema, obtido através da 
decomposigào em sub-sistemas, oferecendo recursos para a representagào de 
sistemas complexos, através da aplicagào de alguns principios bàsicos (Booch et al, 
1999) (Letti ngwell & Widrig, 2000): 

• A escolha de qual modelo criar tem urna profunda influència do modo corno o 

problema é atacado e de corno a solugào é formatada. 

• Cada modelo pode ser expresso em diferentes niveis de precisào e 

detalhamento. 

• Os melhores modelos estào conectados com a realidade. 

• Nenhum modelo é suficiente. Cada sistema um pouco mais complicado é mais 

eficientemente representado por um pequeno conjunto de modelos 
independentes. 

• Distribuigào e partigào de funcionalidades sào otimizadas para atingir 

totalmente as funcionalidades do sistema com minimo custo e màxima 
funcionalidade. 

O engenheiro de sistemas modifica a influència relativa de diferentes 
elementos do sistema (pessoal, hardware e software) para derivar os diversos tipos 
de modelos, sempre considerando vàrios fatores restritivos corno premissas, 
simplificagòes, limitagées, restrigées e preferèncias (Pressman, 2006). 

A engenharia de sistemas està dividida em duas partes: caracterizagào do 
problema e anàlise do sistema. As atividades de caracterizagào do sistema tratam 
da criagào, implementagào e modificagào dos sistemas. As atividades associadas à 
anàlise do sistema tratam da escolha, entre vàrias alternativas possiveis, de solugào 
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do problema. O modelo obtido no processo de engenharia de sistemas pode adotar 
urna solugào completamente automatizada, urna solugào semi-automatizada ou um 
enfoque nào automatizado (Kintschner, 2003) (Pressman, 2006). 

A engenharia de sistemas oferece um conjunto de principios bàsicos a serem 
utilizados corno tècnica de anàlise. Sào eles (INCOSE, 07) (Leffingwell & Widrig, 00): 

• Conhecer o problema, conhecer o cliente e conhecer o usuàrio. 

• Utilizar critérios baseados em necessidades efetivas para as decisoes do 

sistema. 

• Estabelecer e gerenciar os requisitos; 

• Identificar e avaliar alternativas que sejam convergentes para a solugào. 

• Verificar e validar requisitos e solugàes de desempenho. 

• Manter a integridade do sistema. 

• Utilizar um processo de documentagào adequado. 

• Gerenciar de acordo com o plano. 

2.2 ENGENHARIA DE PROCESSOS DE NEGÓCIO 

Desde os primórdios da humanidade, o homem busca produzir bens e servigos 
que promovam melhoria em sua qualidade de vida. Com a introdugào do dinheiro em 
substituigào aos mecanismos de troca de mercadorias, surgiram novos e 
sofisticados métodos para tratamento das mercadorias, seus custos e pregos, e 
respectiva contabilizagào, incrementando, de forma significativa, a complexidade dos 
processos de negócio das organizagòes. (Marshall, 2000). 

A intensa concorrència e as pressoes económicas sobre as grandes 
organizagòes no final do século passado mostraram que a iniciativa de melhoria de 
qualidade e de melhoria continua e paulatina dos processos, embora essenciais, 
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nào sào suficientes para a manutengào dos negócios. O desempenho comercial està 
condicionado a urna abordagem revolucionària que deve abranger tanto a maneira 
de ver e estruturar a atividade, corno também a maneira de melhorà-la, As atividades 
empresariais precisam ser tratadas corno processos-chave ao invés de fungóes, 
departamentos e produtos. A realizagào de niveis de melhoria dessa ordem de 
magnitude em tais processos significa seu replanejamento do principio ao firn, com 
emprego de todas as tecnologias inovadoras e recursos organizacionais disponiveis 
(Davenport, 1994). 

A complexidade dos processos de negócio das organizagóes, que envolvem 
um grande nùmero de entidades e pessoas, implica a utilizagào de estruturas e 
modelos adequados para a gestào destes processos, mantendo o foco na finalidade 
da organizagào, mantendo assim, a organizagào viva e lucrativa. Organizagóes de 
sucesso desenvolvem estratégias para definir e atingir suas finalidades. A finalidade 
de urna organizagào abrange sua visào, missào, metas e objetivos, os quais sào 
alcangados através dos processos de negócio. Os processos de negócio devem 
abranger também os relacionamentos e comunicagóes entre diferentes 
organizagóes, permitindo que trabalhem juntas e se comuniquem (Rukanova et al, 
2005) (Marshall, 2000). 

Um processo de negócio requer entidades, tais corno, materiais, pessoas, 
equipamentos e tecnologia, os quais a organizagào deve adquirir, desenvolver e 
organizar. Estas entidades estào inter-relacionadas, e a organizagào necessita 
gerencià-las em seus processos de negócio com o objetivo de atingir a finalidade 
Principal da organizagào (Marshall, 2000). 
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2.2.1 Processos de negócio 

Definigóes sobre processo sào encontradas em diversos ramos da ciència e 
sempre com significados semelhantes, embora sejam tratados em assuntos 
diferentes, corno segue: 

• Processo representa o fluxo de trabalho e informagóes existente durante todo o 

negócio. Estes processos atuam nas entidades de negócio para realizar as 
fungóes de negócio. Processos de negócio podem ter longa duragào ou curta 
duragào. Processos de negócio de reengenharia tipicamente sào de longa 
duragào (OMG, 2007). 

• Processo é urna ordenagào especifica das atividades no tempo e espago, com 

comego e firn identificado, entradas e saidas claramente identificadas, ou 
seja, urna estrutura para a agào (Davenport, 1994). 

• Processos de negócio sào sistemas sociais e tecnológicos, executados por 

pessoas e màquinas, e apoiados por sistemas de gerenciamento de 
processos de negócio (Shaw et al, 2007). 

• Processo de negócio define corno urna organizagào atinge suas finalidades. 

Processos estratégicos desenvolvem a visào e a missào, processos tàticos e 
operacionais sào utilizados para atingir as metas e os objetivos da 
organizagào. Um processo de negócio pode abranger um simples processo 
linear com poucos passos ou urna rede complexa de atividades 
interdependentes (Marshall, 2000). 

• Os processos de negócio oferecem urna visào completa e dinàmica de urna 

organizagào, identificando e agrupando atividades dependentes executadas 
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por departamentos diferentes, muitas vezes separados hieràrquica e 
funcionalmente, agregando valor ao cliente (Damij, 2007). 

Urna caracteristica encontrada na maioria dos processos, principalmente nos 
processos de negócios, é a sua inter-funcionalidade, ou seja, nào sào executados 
inteiramente em urna ùnica àrea funcional (Kintschner, 2003). 

Um processo de negócio é constituido de etapas, representadas por urna ùnica 
unidade de traballio, ou também denominada atividade ou transagào, que pode ser 
executada completa ou parcialmente. Urna etapa de processo identifica unicamente 
um evento de negócio, e pode ser utilizada para auditoria e acompanhamento. Urna 
etapa de processo pode acessar e alterar o estado de urna ou vàrias entidades de 
negócio. Pessoas sào partes integrantes de qualquer processo que nào esteja 
totalmente automatizado. As etapas de processo possuem urna interface pela qual 
podem ser vistas e controladas por pessoas, os usuàrios do processo. A interface do 
processo com o usuàrio permite que este atue sobre atributos do processo, além de 
permitir que agóes sejam tomadas, corno iniciar, parar, suspender, restaurar, 
cancelar ou completar urna etapa de processo (Marshall, 2000). 

As organizagòes necessitam se adaptar, de forma flexivel e ràpida, às 
constantes mudangas no ambiente empresarial do mundo globalizado. Seu 
desempenho competitivo depende de sua habilidade de atender exigèncias 
endógenas e exógenas de mudangas, tais corno, evolugào do ciclo de vida de 
produto, novos concorrentes ou alteragóes politicas e econòmicas. Os processos de 
negócio devem evoluir de forma adequada e flexivel para acompanhar as constantes 
e repetitivas transformagóes das organizagóes (Korthaus, 1998). 

Os processos de negócio, geralmente, possuem um alto grau de complexidade 
e sào realizados por urna sequència mais detalhada de etapas. Um processo é 
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composto de um conjunto de etapas, ou atividades, organizadas de acordo com 
regras que definem a sequència e a dependència entre elas (Marshall, 2000). 

As organizagòes estào se focando cada vez mais em seus processos do 
negócio, resultando em um interesse crescente por melhores pràticas de 
reengenharia. Dois problemas afloram da utilizagào destas melhores pràticas: corno 
encontrar, entre as melhores pràticas, a que se adapte às finalidades da 
organizagào; e corno assegurar que a melhor pràtica selecionada possua a mesma 
natureza do processo de negócio sob re-engenharia. Andersson et al (2005) propoe 
corno solugào deste problema utilizar processos de negócio padronizados (BPP - 
Business Process Patterns) e um mètodo para realizar urna comparagào formai 
entre os processos de negócio atual e os novos processos de negócio oriundos das 
melhores pràticas. 

Barros (2007) propoe um mètodo baseado em processos de negócio 
padronizados (BPP - Business Process Patterns ) e arcabougos ( frameworks ) que 
permite formai e logicamente a reutilizagào de conhecimento na criagào e revisào 
dos processos de negócio das organizagóes. 

A tecnologia da informagào possui um grande potencial para auxiliar e 
automatizar partes dos processos de negócio (Akhavan et al, 2006). Entretanto, isto 
requer que as aplicagóes possam expressar e interpretar urna grande quantidade de 
informagóes e significados para estas informagóes. Ou seja, as aplicagóes que 
suportam os processos de negócio precisam ir além da simples expressào das 
informagóes, elas precisam interpretar de forma inteligente as informagóes para 
entender o seu significado (Rukanova et al, 2005). 

Em seu trabalho, Rukanova (2005), apresenta urna alternativa para satisfazer 
este contexto operacional, utilizando padróes ou Standards , agrupados em très tipos 
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principais: padróes que definem o significado dos dados; os padròes que descrevem 
o que é comunicado em urna mensagem; e os padròes que definem as intengòes da 
mensagem (Rukanova, 2005) e (Rukanova et al, 2005). 

Sistemas de gerenciamento de processos de negócio ou BPMS 2 sào 
ambientes associados à tecnologia da informagào que oferecem ferramentas para a 
implementagào de urna abordagem administrativa da gestào por processos, 
oferecendo recursos para a modelagem, integrafo, construgào, execugào e 
manutengào dos processos de negócio da organizagào (De Sordi & Spelta, 2007) 
(Shaw et al, 2007). 

Em seu trabalho, “Elements of a business process management System: theory 
and practice" (Shaw et al, 2007), Shaw apresenta, baseado em urna extensa revisào 
da literatura acadèmica e comercial, os elementos comuns encontrados nos 
principais BMPS (Figura 1). A arquitetura em forma de piràmide representa duas 
dimensóes, urna tratando as questoes sintàticas, semànticas e pragmàticas e, a 
outra, representando o lado tecnològico dos BPMS. A Tabela 1 apresenta urna breve 
descrigào de cada um dos elementos que compòem um BPMS. 


2 Business Process Management Systems 



BPMS 


Modelo de Processo de 
Negócio Executàvel 


Construtores 
Formais de modelo 


Aplicagào 


Notagào 
Formai de 
Modelagem 


Gramàtica 

de 

Modelagem 


Linguagem 

de 

Programagào 


Modelo Abstrato 


Infra- 

estrutura 

Tècnica 


Notagào 


Gramà- 

tica 


Processo de negócio 
modelado 


Formalismo da 
linguagem de 
programagào 


Figura 1 - Arquitetura BPMS proposta por Shaw et al (2007) 
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Tabela 1 - Descrigào elementos da arquitetura BPMS (Shaw et al, 2007) 


Elemento 

Descrigào 

BPMS 

Ambiente para modelagem, integragào e 
execugào destinado ao design, construgào e 
manutengào de processos de negócio 

Modelo de processo 
de negócio executàvel 

Elemento que permite a execugào dos 
modelos de processo de negócio 

Construtores formais 
de modelo 

Elementos que compòem um modelo 
executàvel 

Notagào formai de 
modelagem 

Conjunto de simbolos usados para 
representar os construtores formais de 
modelo 

Gramàtica de 
modelagem 

Conjunto de regras que definem os 
construtores formais de modelo 

Modelo abstrato 

Abstragào da realidade descrita pela 
gramàtica de modelagem 

Processo de negócio 
modelado 

Processo de negócio que està sendo tratado 
pelo BPMS 

Aplicagào 

Software que implementa o BPMS 

Infra-estrutura tècnica 

Sistema operacional e o hardware que 
suportam a aplicagào 

Linguagem de 
programagào 

Linguagem de programagào utilizada para 
implementar a aplicagào 

Notagào da linguagem 
de programagào 

Notagào da linguagem de programagào 
utilizada para implementar a aplicagào 

Gramàtica da 
linguagem de 
programagào 

Gramàtica da linguagem de programagào 
utilizada para implementar a aplicagào 

Formalismo da 
linguagem de 
programagào 

Formalismo da linguagem de programagào 
utilizada para implementar a aplicagào que 
define capacidade de prova matemàtica de 
suas propriedades 


2.2.2 Modelagem de Processos de Negócio 


Para Santos et al (2002), a engenharia de processos de negócio é fortemente 
suportada por modelos de processos destinados a urna melhor compreensào da 
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organizagào. A modelagem de processos de negócio possui um conjunto de 
finalidades bàsicas destinadas à representagào, anàlise e melhoria da forma corno o 
trabalho é realizado horizontalmente, orientado para produtos, clientes e mercados, 
nas organizagóes. A modelagem de processos de negócio oferece suporte para um 
conjunto de aplicagóes da engenharia de processos de negócio: redesenho de 
processo; anàlise e melhorias de processos; sistemas integrados de gestào; projeto 
de sistemas de informagào; identificagào, selegào e monitoragào de indicadores de 
desempenho; anàlises organizacionais; gerència do conhecimento; workflow e 
gerència de documentos; organizagào de documentagào tècnica; benchmarking 
entre as formas de trabalho; integragào organizacional através da uniformizagào de 
entendimentos sobre a forma de trabalho; modelos de negócios eletrónicos; e cadeia 
de suprimentos. 

Um modelo de negócio é urna abstragào do funcionamento do pròprio negócio 
e deve possuir os seguintes componentes (Dias et al, 2006) (Marshall, 2000) 
(Korthaus, 1998): 

• Os objetivos sào os propósitos do negócio, ou simplesmente, os resultados que 

toda a organizagào deseja atingir. 

• Os recursos constituem os objetos utilizados em um negócio, tais corno 

pessoa, material, informagào ou produto. 

• Os processos constituem um conjunto de atividades estruturadas para que um 

produto, que pode ser um bem ou um servilo, possa ser gerado. 

• As regras sào declaragóes que restringem, derivam e fornecem condigóes de 

existència, representando o conhecimento do negócio. 

A definigào de padróes e pràticas comuns à modelagem permite dirimir as 
questóes especificas ou polèmicas inerentes a um determinado modelo, oferecendo 
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a todas as pessoas envolvidas no traballio de modelagem de negócio urna forma 
assemelhada de trabalhar e descrever processo. Os padróes e as pràticas comuns 
refletem diretamente na legibilidade, percepgào da qualidade e homogeneidade no 
resultado obtido com a modelagem dos processos de negócio (Cameira & 
Caulliraux, 2000). 

Na busca por padròes de modelagem, diversos métodos de modelagem de 
negócio foram desenvolvidos com o intuito de facilitar o processo de modelagem 
empresarial através de métodos pré-definidos que pudessem ser reutilizados. Os 
métodos de modelagem de negócio oferecem a engenharia de processos de 
negócio um referencial ùnico, integrado e articulado para o tratamento da 
modelagem de negócio. Seguem alguns destes métodos (Santos et al, 2002) 
(Vicente, 2004): 

• Architecture of integrateci information systems - ARIS (IDS, 2007): este mètodo 
tem corno principal objetivo, através de modelos, estabelecer urna visào 
holistica, integrada e homogènea de urna organizagào, permitindo o 
desenvolvimento de sistemas de informagào mais aderentes ao negócio. Este 
mètodo està fundamentado na integragào dos processos de negócios da 
organizagào através do agrupamento dos modelos em cinco vistas 
interligadas: organizagào, fungào, dados, saida, e controle ou processo. Sào 
diversos modelos associados a cada vista, que se inter-relacionam, 
mostrando, de maneira consistente, desde a concepgào e o entendimento 
estratégico da organizagào até os componentes de implementagào dos 
sistemas, com destaque para os seguintes modelos: o Diagrama de 
Objetivos, o Organograma, a Cadeia de Valor Agregado, a Cadeia de Eventos 
Orientados a Processos e o Diagrama de Caso de Uso. 
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• Integrateci DEFinition - IDEF (IDEF, 2007): O mètodo IDEF comegou a ser 

criado nos anos 70 pela forga aèrea dos Estados Unidos da América para o 
tratamento apenas de sistemas. O IDEF, com o passar dos anos, foi 
agregando novos métodos relacionados a diversos aspectos organizacionais 
e atualmente è composto por diversos sub-métodos: IDEF 0, relacionado à 
modelagem funcional; IDEF 1, para modelagem de informagèes; IDEF 2, 
desenvolvido para suportar simulagèes; IDEF 3, para descrigào e captura de 
processos; IDEF 4, para modelagem orientada a objetos; e IDEF 5, para 
descrigào de ontologias. O mètodo IDEF 3 està diretamente relacionado à 
modelagem de processos, sendo composto por dois modelos denominados 
Modelos de Fluxo de Processo ( Process Flow), que descreve corno as coisas 
sào feitas dentro de um processo de produgào, e Modelo de Rede de 
Transigaci de Estado de Objeto ( Object State Transition Network - OSTN), que 
descreve os eventos pelos quais um objeto passa em um determinado 
processo. 

• Computer Integrateci Manufacturing Open System Architecture - CIMOSA 

(Vernadat, 1996): introduziu o conceito de arquitetura de sistemas abertos 
para CIM ( Computer Integrateci Manufacturing), através da padronizagào de 
módulos, descritos em termos de sua fungào, informagào, recurso e aspectos 
organizacionais, oferecendo urna arquitetura capaz de auxiliar as 
organizagòes a gerenciar mudangas e integrar suas facilidades e operagòes 
com o objetivo de obter pregos, qualidade e prazos de entrega competitivos. 
CIMOSA è urna arquitetura consistente tanto para a modelagem corno para a 
integragào empresarial e possui 3 componentes principais: estrutura de 
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modelagem empresarial, a infra-estrutura de integrataci e ciclo de vida do 
sistema CIM. 

Vicente (2004) analisa as técnicas de modelagem de processos de negócio e 
as técnicas de modelagem de sistemas e propòe um mètodo de modelagem de 
processos e requisitos de negócio, baseada em Unified Modeling Language (UML), 
capaz de apoiar a especificagào e o projeto de um sistema integrando os requisitos 
de negócio com os requisitos de sistemas. Nesse traballio, Vicente apresenta os 
principais conceitos, metodologias, ferramentas, aplicagóes e ganhos da engenharia 
de processos de negócio, ressaltando a importància da integragào e do alinhamento 
entre a estratégia concebida para um negócio, seus processos e os sistemas que o 
suportam. 

Para Damij (2007), existem diversas técnicas de modelagem de processos de 
negócio que podem ser divididas em dois grupos bàsicos: técnicas baseadas em 
diagramas e técnicas baseadas em tabelas. Em seu trabalho, Damij (2007) 
apresenta e compara técnicas de modelagem de processos de negócio e conclui 
que as técnicas devem ser utilizadas em conjunto, comegando por um tratamento 
tabular e continuando com um tratamento diagramàtico. 

Salm (2003) trata a modelagem de processos de negócio utilizando urna 
linguagem de modelagem orientada a objetos, a Unified Modeling Language (UML), 
mostrando que os artefatos produzidos na etapa de design e construgào sào 
guiados por modelos criados na disciplina de modelagem de processos de negócio e 
concluindo que a utilizagào da UML na modelagem de processos de negócio implica 
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a busca de extensóes 3 da UML que permitam o tratamento adequado das 
necessidades impostas pela disciplina de modelagem de negócio. 

Para Vicente (2004), é necessàrio definir um mètodo de modelagem de 
processos com foco no desenvolvimento em sistemas, mesclando as principais 
etapas de modelagem de processos de negócio com algumas das etapas de 
modelagem de sistemas de informagào. Conclui que o processo de desenvolvimento 
de sistemas proposto pelo Rational Unified Process (RUP), corno arcabougo para o 
desenvolvimento de sistemas de informagào, permite verificar de que forma os 
diagramas da UML sào utilizados para a modelagem de negócio dentro de um 
processo de desenvolvimento de um sistema de informagào. 

2.2.3 Modelagem de Negócio com UML 

A Unified Modeling Language (UML) é urna linguagem gràfica que permite a 
visualizagào, especificagào, construgào e documentagào dos artefatos que 
compóem um sistema de software. A UML é urna linguagem para modelagem, com 
vocabulàrio e regras originalmente focados na representagào conceitual e fisica de 
um sistema de software, que pode ser utilizada para modelagem de negócio e de 
sistemas em geral (Booch et al, 1999) (OMG, 2007). 

Existem diversos trabalhos (Korthaus, 1998) (Marshall, 2000) (Noran, 2000) 
(Baker, 2001) (Jackowski, 2003) (Salm, 2003) (Vicente, 2004), utilizando UML 1 
corno linguagem gràfica para a modelagem de negócio, tratando de forma 


3 A UML pode ser estendida ou adaptada para um mètodo especlfico, urna organizagào ou um 
usuàrio, através de elementos de modelagem que permitem o tratamento visual especializado e 
definem corno criar novas semànticas (Salm, 2003) (OMGUML, 2007). 
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abrangente està questào, descrevendo os passos e os recursos a serem utilizados, 
e indicando os problemas, as dificuldades e as inconsistèncias encontradas. 

Vicente (2004) conclui que a modelagem de negócios com os modelos da UML 
versào 1, apesar de apresentar vantagens de entendimento por parte dos analistas 
desenvolvedores de sistemas, apresenta limitagòes de entendimento por parte dos 
analistas de negócio, pois, quando comparados com as técnicas de modelagem de 
negócio tradicionais, os modelos da UML nào representam de forma satisfatória 
alguns conceitos relacionados à modelagem de negócio. 

Em seu trabalho Vicente (2004) utiliza a proposta de extensào da UML versào 
1 de Eriksson & Penker (1999) apud Vicente (2004), destinada à modelagem de 
negócio, com urna proposta de arquitetura dividida em vistas suportadas por 
modelos e extensóes da UML, onde é obtido um maior acoplamento com as 
necessidades da modelagem de processos de negócio e utilizando, principalmente, 
o diagrama de atividades, para representar conceitos inerentes aos conceitos de 
processos de negócio. Nesta proposta, as principais limitagòes encontradas sào a 
falta de capacidade de abstragào nos niveis de detalhamento e a limitagào para 
representar sistemas de informagào que suportem estruturas de processos de 
negócio mais complexas. 

Desde a sua apresentagào, em 1997, a UML vem se tornando o padrào para a 
modelagem orientada a objetos de projetos de desenvolvimento de software. A UML 
versào 2.0, ou UML 2, apresentada pela OMG (OMG, 2007) (OMGUML, 2007) em 
2004, inclui 13 notagóes distintas de modelagem, variando desde diagramas de alto 
nivel, corno o diagrama de casos de uso, que descrevem as interagóes e os 
relacionamentos entre atores e as fungóes bàsicas de negócio, até diagramas de 
baixo nivel, corno os diagramas de objetos, que capturam instàncias de objetos 
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individuas de dados. As notagèes de modelagem podem ser divididas em très 
grupos (Russel et al, 2006) (OMGUML, 2007): 

• Diagramas de estrutura, que capturam a estrutura de estàtica do sistema em 

diversos niveis de abstragào, incluindo: o diagrama de classe, o diagrama de 
objeto, o diagrama de componentes, o diagrama composigào de estrutura, o 
diagrama de pacotes e o diagrama de distribuigào. 

• Diagramas do comportamento, que fornecem urna abstragào de alto nivel para 

as funcionalidades do sistema, incluindo: o diagrama de caso de uso, 
diagrama da atividade e o diagrama de màquina de estado. 

• Diagramas da interagào, que fornecem urna descrigào mais detalhada das 

funcionalidades do sistema, incluindo as interagèes entre os objetos, 
incluindo: o diagrama de sequència, o diagrama de comunicagào, o diagrama 
temporal e o diagrama de visào geral da interagào. 

UML 2 é urna linguagem independente de ferramenta ou mètodo utilizado para 
o desenvolvimento de sistemas. Pode ser utilizado XMI (XML 4 Metadata 
Interchange) para a transferéncia dos modelos UML existentes no repositório de 
urna determinada ferramenta, para o repositório de outra ferramenta que oferega o 
maior refinamento ou o detalhamento necessàrio para urna etapa posterior 
estabelecida no mètodo de desenvolvimento. XMI è um padrào da OMG para troca 
de informagèes baseado em XML, onde o uso mais comum è na troca facilitada de 


4 XML (eXtensible Markup Language) é urna linguagem capaz de descrever diversos tipos de dados, 
onde o propòsito principal é a facilidade de compartilhamento de informagòes através da Internet 
(W3CXML, 2008). 
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dados entre as ferramentas de modelagem baseadas em UML e os repositórios 
MOF 5 (OMGUML, 2007). 

A UML 2.0 permite navegar entre diversos niveis de abstragào e detalhes do 
sistema. Isto é, partindo de urna vista detalhada da aplicagào chega-se ao ambiente 
onde a aplicagào està sendo executada, ou até mesmo ao processo de negócio ou à 
regra de negócio que a aplicagào està automatizando (OMGUML, 2007). 

De acordo com Selic (2006), a UML 2.0 apresenta um conjunto de diferengas 
em relagào às versòes anteriores, as quais estào listadas a seguir: 

• Maior precisào na definigào da linguagem: necessàrio para oferecer maiores 

niveis de automagào, inerentes ao desenvolvimento orientado a modelo (MDD 
Model Driven Development), que requerem a eliminagào de ambiguidades e 
imprecisóes nos modelos. 

• Arquitetura altamente modular da linguagem: que permite que a linguagem 

possa ser aprendida e utilizada de forma graduai, de acordo com as 
exigèncias de sofisticagào do dominio e do projeto. 

• Novos recursos de modelagem: a maioria dos novos recursos de modelagem 

da UML 2 sào extensóes daqueles jà existentes e que, geralmente, permitem 
a modelagem mais direta e escalàvel de complexas aplicagóes distribuidas. 
Para conseguir ser escalàvel, muitos dos conceitos de modelagem da UML 2 
sào recursivos, permitindo que sistemas muito complexos sejam 


5 MOF ( MetaObject Facility Specification ) é um ambiente padronizado onde os modelos podem ser 
exportados de urna aplicagào, importados em outra, transportados pela internet, armazenados ou 
recuperados de um repositório, traduzido ou transformado para outro formato, e utilizado para gerar o 
código da aplicagào. (OMGMOF, 2007) 
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representados mediante a utilizalo de composigào e decomposigào 
hieràrquica. 

• Suporte aprimorado para linguagens de dominio especifico: mesmo que a UML 
2 padrào possa ser utilizada sem especializagào adicional, a UML 2 é 
essencialmente urna linguagem de uso geral bàsica, que pode derivar 
linguagens de dominio especifico altamente especializadas, oferecendo 
vantagens na reutilizagào direta de ferramentas UML e da capacitalo 
existente das equipes de desenvolvimento. 

As versóes iniciais da UML eram basicamente baseadas no paradigma de 
orientagào a objetos do desenvolvimento de software. A UML 2 oferece novos 
recursos para modelagem baseados na visào funcional de comportamento e na 
evolugào do formalismo do modelo de atividades, que permitem a utilizagào de UML 
2 em outros dominios, corno modelagem de processos de negócio e engenharia de 
sistemas. Na UML 2 o diagrama de atividades possui o fundamento semàntico 
baseado em Redes de Petri, ao invés do fundamento mais restrito oferecido pelas 
màquinas de estado utilizadas nas versòes anteriores da UML (Selic, 2006). 

Para Russell et al (2006), o diagrama de atividades da UML 2.0 tem mèrito 
corno urna notagào para modelagem de processos do negócio, entretanto nào é 
apropriado para todos os aspectos deste tipo de modelagem. O diagrama de 
atividades oferece urna sustentagào detalhada para o controle de fluxo e para a 
perspectiva de dados, permitindo a modelagem direta da maioria das construgóes 
necessàrias para representar estas perspectivas. Entretanto, oferece urna 
sustentagào extremamente limitada para a modelagem dos aspectos relacionados a 
recursos ou aspectos organizacionais dos processos de negócio, pois nào permite 
capturar grande parte das construgóes bàsicas encontradas nos processos do 



41 


negócio, corno por exemplo, a nogào de interagào corri o ambiente operacional onde 
os processo funcionam. Cabe ressaltar que estas lirmitagóes também sào 
encontradas em grande parte das demais ferramentas para modelagem de negócio. 

2.3 PROCESSO UNIFICADO 

Segundo Pressman (2006), o processo unificado é urna tentativa de utilizar os 
melhores recursos e caracteristicas dos modelos convencionais de engenharia de 
software, reconhecendo a importància da comunicagào com o cliente e da 
arquitetura de software, através de um fluxo de processo iterativo e incrementai, 
baseado na utilizagào de urna linguagem gràfica de modelagem, Unified Modeling 
Language (UML). 

Os métodos e linguagens de programagào orientada a objetos ganharam urna 
grande audiència na comunidade de engenharia de software nas décadas de 1980 e 
1990, onde surgiram diversos métodos de anàlise orientada a objetos e de projeto 
orientada a objetos (Pressman, 2006). Entretanto em 1967 os sistemas jà eram 
modelados com um conjunto de blocos interconectados, iniciando um processo com 
cerca de très décadas de evolugào e amadurecimento para o processo unificado, 
surgindo o O bjectory Process em 1985, sucedido pelo Rational Objectory Process 
4.1 em 1997, que incorporou a UML e finalmente em 1998 o Rational Unified 
Process 5.0 (Jacobson et al, 1999). 

O processo unificado é um processo de engenharia de software, formado por 
um conjunto de atividades que objetivam transformar os requisitos dos stakeholders 
em um sistema de software. O processo unificado é baseado em componentes, 
utiliza UML (Booch et al, 1999) (Gilleanes, 2004) corno elemento bàsico para a 
apresentagào de toda a documentagào do sistema, é dirigido a casos de uso, além 
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de ser um processo centrado na evolugào da arquitetura 6 e apresentar urna 
abordagem iterativa e incrementai (Jacobson et al, 1999). 

2.3.1 Rational Unified Process - RUP 

O RUP é um arcabougo para a engenharia de software orientada a objetos, 
formado por um conjunto de atividades necessàrias para transformar os requisitos 
dos stakeholders em um conjunto consistente de artefatos que representam um 
produto de software. O RUP utiliza um conjunto de disciplinas para atribuir tarefas e 
responsabilidades dentro de urna organizagào de desenvolvimento de software. Sua 
meta é garantir a produgào de software de alta qualidade que atenda às 
necessidades dos usuàrios, dentro de um cronograma e um orgamento previsiveis 
(Kruchten, 2000) (Pressman, 2006) (IBMRational, 2008). 

O RUP busca capturar as melhores pràticas da engenharia de software, tais 
corno (Kruchten, 2000): 

• Desenvolvimento de software iterativo, que busca a divisào do projeto em 

vàrios projetos menores ou iteragòes 

• Gerenciamento de requisitos, que busca de forma sistemàtica a eliciagào, 

organizagào, comunicagào e gerenciamento das mudangas dos requisitos do 
sistema, permitindo avaliar e estimar os impactos das alteragòes. 

• Utilizagào de arquitetura baseada em componentes, que busca produzir e 

validar a arquitetura de software nas etapas iniciais do ciclo de 
desenvolvimento, além de privilegiar a reutilizagào de software. 


6 Architecture-centric 
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• Modelagem visual, que, baseada na UML, busca auxiliar na especificagào, 

construgào, documentataci e comunicagào dos elementos do projeto, 
permitindo exibigào ou inibigào de detalhes de acordo com a visào a ser 
oferecida do sistema. 

• Verificagào continua de qualidade de software, que busca distribuir a 

responsabilidade da qualidade, tanto do projeto corno do produto, por toda a 
equipe de desenvolvimento. 

• Controle de mudangas, que busca, de forma sistemàtica, o gerenciamento das 

mudangas nos requisitos, no design e na implementagào. 

O RUP apresenta urna abordagem iterativa em espirai e incrementai, em que o 
projeto é dividido em vàrios projetos ou iteragòes. Cada iteragào possui um conjunto 
definido de objetivos, direcionando a equipe de desenvolvimento para a obtengào de 
artefatos que convergem para o produto final esperado pelos stakehoiders, 
oferecendo urna estratégia de desenvolvimento na qual o sistema é construido 
adicionando-se mais funcionalidades a cada iteragào. Cada iteragào apresenta 
elementos associadas à gerència de requisitos, anàlise e design, implementagào, 
integragào e testes. O RUP oferece urna estrutura iterativa onde o projeto é 
organizado em quatro fases: iniciagào, buscando compreender o que deve ser feito 
através da definigào do escopo do sistema; elaboragào, buscando compreender 
corno fazer através da definigào da arquitetura do sistema; construgào, buscando o 
desenvolvimento de urna versào preliminar do produto; e transigào, buscando a 
construgào da versào final do produto a ser implantada (Kroll, 2001). 

A abordagem utilizando um modelo em espirai (Boehm, 1988) permite a 
identificagào dos riscos existentes no projeto de forma antecipada dentro do ciclo de 
vida, sendo possivel tratar os riscos de forma eficiente e no momento adequado, 
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permitindo a redugào de custos e urna estimativa mais precisa dos prazos de 
desenvolvimento (Kroll, 2001). 

O RUP é um processo que compreende as atividades das vàrias fases do ciclo 
de desenvolvimento do software, comegando pela atividade de modelagem de 
negócio, passando pelas atividades de requisitos, anàlise, design, implementagào, 
testes e impiantalo (Figura 2). O RUP està estruturado em duas dimensòes 
(Kruchten, 2000): 

• O eixo horizontal representa o tempo e os aspectos do ciclo de vida do 

desenvolvimento. Està dimensào representa o aspecto dinàmico do processo 
e é expressa em termos de eidos, fases, iteragòes e marcos. 

• O eixo vertical representa as disciplinas, que agrupam as atividades de 

maneira lògica, de acordo com a sua natureza. Està dimensào representa o 
aspecto estàtico do processo de desenvolvimento e de corno o processo é 
descrito em termos de componentes, disciplinas, atividades, fluxos de 


traballio, artefatos e papéis. 
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Figura 2 - Estrutura do RUP em duas dimensòes (Kruchten, 2000) 

Os requisitos do sistema sào eliciados, nào só para se encontrar a 
especificagào do sistema, mas também para se criar urna representagào comum 
para todos os integrantes da equipe de desenvolvimento e para os stakeholders. 
Geralmente, um sistema possui diversos tipos de usuàrios, onde cada tipo é 
representado por um ator. Um caso de uso descreve a forma corno um ator interage 
com o sistema, através de urna sequència de agòes que o sistema executa para 
oferecer resultados aos atores. O conjunto formado por todos os atores e todos os 


casos de uso resulta no modelo de casos de uso do sistema (Jacobson et al, 1999). 
O RUP é dirigido pela utilizalo de casos de uso 7 , onde a identificagào de casos de 


uso e cenàrios tipicos de utilizagào é a atividade que conduz todo o processo de 
desenvolvimento, desde a anàlise de requisitos até o teste do sistema final. A 
utilizagào dos casos de uso permite que a equipe de desenvolvimento trabalhe de 


46 


forma próxima aos requisitos durante o design, implementagào e testes, garantindo 
que os requisitos serào atendidos. 

O RUP contempla e reconhece em seu processo de desenvolvimento a 
modelagem do negócio corno sendo urna disciplina fundamental para o 
desenvolvimento de sistemas e fornece técnicas de modelagem de negócio, mais 
especificamente os casos de uso de negócio, para representar processos de 
negócio. Entretanto està proposta de representagào apresenta limitagóes quanto à 
representagào e modelagem dos fluxos dos processos de negócio e suas 
integragòes, e também quanto ao alinhamento dos casos de uso identificados com 
os objetivos do negócio. Estas limitagóes podem ser contornadas integrando-se de 
forma mais consistente os conceitos de modelagem de processos de negócio com 
os conceitos de modelagem de sistemas, buscando a redugào do tempo de 
transigào entre os processos de negócio e o desenvolvimento dos sistemas e 
procurando uniformizar o entendimento geral entre analistas de negócio e de 
sistemas (Vicente, 2004). 

2.4 ENGENHARIA DE REQUISITOS 

No processo de desenvolvimento de sistemas é geralmente das etapas iniciais 
que decorre a maior parte dos problemas, no minimo sào aqueles mais dispendiosos 
e de maior impacto negativo. Estas etapas constituem o processo de engenharia de 
requisitos, que tem sido reconhecida corno urna das mais importantes fases do 
processo de engenharia de software (Kotonya & Sommerville, 1998). 


7 Do termo em inglès Use-Case Driven. 
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A Figura 3 apresenta a relagào entre o custo para reparar um problema de 
acordo com a fase em que este foi descoberto, dentro das etapas do ciclo de vida do 
desenvolvimento do sistema. O custo de um problema tratado quando o sistema 
està em produgào é 500 vezes maior do que se fosse detectado e tratado na fase de 
requisitos (Carr, 2000). 



Figura 3 - Custo para corrigir problema no desenvolvimento de sistemas (Carr, 2000) 
Leffingwell & Widrig (2000) destacam que a causa raiz do sucesso ou falha no 
desenvolvimento de um sistema està relacionado com os requisitos do sistema e, 
para fundamentar a afirmagào, incluem em seu trabalho o estudo do Standish Group 
(1995), que indica que os trés principais fatores causadores de problemas nos 
projetos de desenvolvimento de software sào: falta de participagào dos usuàrios 
(13%), especificagòes e requisitos incompletos (12%), e alteragào nas 
especificagòes e requisitos (12%). 
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Leffingwell & Widrig (2000) destacam ainda a pesquisa realizada por ESPITI 8 
em 1995, onde, através de 3800 respostas objetivando determinar os principais 
problemas encontrados no desenvolvimento de software, sào identificados os dois 
principais problemas: especificagào de requisitos e gerenciamento dos requisitos. 

2.4.1 Definigòes 

A engenharia de requisitos ajuda os engenheiros a compreenderem melhor o 
problema, através de um conjunto de tarefas que levam a um entendimento de qual 
sera o impacto do sistema sobre o negócio, do que o stakeholder necessita e de 
corno os usuàrios finais interagito com o sistema (Pressman, 2006). 

Segundo Kotonya & Sommerville (1998), engenharia de requisitos é o processo 
sistemàtico de eliciagào, entendimento, anàlise e documentagào dos requisitos, 
onde o termo engenharia implica a utilizagào de um processo pràtico, sistemàtico e 
repetitivo visando assegurar que os requisitos do sistema sejam completos, 
consistentes e relevantes. 

Segundo Carr (2000), requisitos sào as descrigàes das propriedades, dos 
atributos, dos servigos, das fungàes e dos comportamentos necessàrios em um 
produto para desempenhar os objetivos e finalidades do sistema. Um requisito define 
urna necessidade e nào deve especificar urna solugào de design. 

Requisitos de sistemas definem o que o sistema necessita fazer e em quais 
circunstàncias deve operar. Requisitos sào definidos nos estàgios iniciais do 
desenvolvimento do sistema corno sendo a especificagào do que serà 
implementado, definindo os servigos que um sistema deve prover e o conjunto de 

8 European Software Process tmprovement Training Iniciative 
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restrigdes de operagào que deve atender. A existència de diversos tipos de 
requisitos, para os mais vàrios tipos de sistemas, torna impossivel descrever urna 
forma padronizada para escrever os requisitos e também definir a melhor forma de 
especificar requisitos. A descrigào dos requisitos de um sistema deve incluir outras 
informagòes complementares corno: informagdes de dominio, informagòes sobre 
padróes a serem seguidos e informagdes sobre interface com outros sistemas. Os 
requisitos nào funcionais definem globalmente as qualidades ou atributos do 
sistema, sendo classificados em très tipos principais: requisitos do produto, 
requisitos do processo e requisitos externos (Kotonya & Sommerville, 98). 

O termo stakeholder pode ser traduzido para o portuguès corno parte 
interessada ou interveniente, refere-se a todos os envolvidos em um processo: 
clientes, colaboradores, investidores, fornecedores, comunidade, organizagòes. O 
processo pode ser um projeto de caràter temporàrio ou o negócio duradouro de urna 
empresa. O sucesso de qualquer empreendimento depende da participagào de 
stakeholders sendo necessàrio assegurar o atendimento à suas expectativas e 
necessidades (Kerzner, 2001). 

Para Leffingwell & Widrig (2000) stakeholder é qualquer um que possa ser 
materialmente afetado pela implementagào de um novo sistema ou de urna nova 
aplicagào. Propòem um conjunto de questòes para auxiliar no processo de definigào 
dos stakeholders (Tabela 2). 

Tabela 2 - Questòes para definigào dos stakeholders (Leffingwell & Widrig, 2000) 

Quem sào os usuàrios do sistema? 

Quem é o cliente que està comprando o sistema? 

Quem serà afetado pelas saidas que o sistema produzirà? 

Quem irà avaliar e aprovar o sistema quando for entregue e colocado em 
produgào? 
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Existe outro usuàrio interno ou externo do sistema que necessite ser 
enderegado? 

Quem irà manter o novo sistema? 

Estes sào todos? 


Segundo Kotonya & Sommerville (1998), os stakeholders do sistema sào as 
pessoas ou organizagòes que serào afetadas pelo sistema e que influenciam de 
forma direta ou indireta os requisitos dele. Os stakeholders incluem os usuàrios 
finais do sistema, gerentes, engenheiros responsàveis pelo desenvolvimento e 
manutengào do sistema, clientes da organizagào que utilizaram os servigos do 
sistema, organizagòes externas destinadas a certificagòes e regulamentagòes, entre 
outros. É fundamental identificar o grau de importància de cada stakeholder para o 
sistema e descobrir seus requisitos. 

Para Kotonya & Sommerville (1998), o documento de requisitos é urna 
definigào oficial dos requisitos do sistema para os clientes, usuàrios finais e 
desenvolvedores. 

Carr (2000) define documento de requisitos corno todo documento que 
descreve as propriedades, os atributos, os servigos, as fungàes e os 
comportamentos necessàrios para realizar os objetivos e as finalidades do sistema. 

2.4.2 Processo de Engenharia de Requisitos 

O processo de engenharia de requisitos é formado por um conjunto de 
atividades destinado a derivar, validar e manter o documento de requisitos do 
sistema. O processo apresenta um conjunto de entradas e um conjunto de saidas, 
representados na Figura 4 (Kotonya & Sommerville, 98): 
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• Informagòes de sistemas existentes (Entrada): informagbes associadas a 

funcionalidades de sistemas existentes sendo substituidos ou demais 
sistemas que irào interagir com o novo sistema. 

• Necessidades dos stakeholders (entrada): descrigào de quais as necessidades 

dos stakeholders devem ser atendidas pelo novo sistema. 

• Padròes organizacionais (entrada): padròes utilizados pela organizagào 

associados a pràticas de desenvolvimento, qualidade, gerenciamento e 
outros. 

• Informagòes de dominio (entrada): Informagòes gerais quanto ao dominio onde 

o sistema sera implantado. 

• Regulamentagòes (entradas): regulamentagòes externas de seguranga, saùde, 

governamental ou ambientai, aplicàveis ao desenvolvimento do novo sistema. 

• Requisitos acordados (saida): descrigào dos requisitos do sistema entendidos e 

aprovados pelos stakeholders. 

• Especificagào do sistema (saida): especificagào detalhada das funcionalidades 

do sistema. 

• Modelos do sistema (saida): conjunto de modelos que descrevem o sistema de 

diferentes perspectivas (modelo de fluxo de dados, modelo de objetos, 
modelo de processo, e outros). 
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Figura 4 - Entradas e saidas do processo de engenharia de software (Kotonya & Sommerville, 

98) 

Para Pressman (2006), o processo de engenharia de requisitos é realizado 
através da execugào de sete fungòes distintasi concepgào, levantamento, 
elaboralo, negociagào, especificagào, validagào e gestào. Algumas destas fungòes 
ocorrem em paralelo e sào adaptadas às necessidades do projeto, entretanto todas 
tem o objetivo de definir as necessidades dos stakeholders, estabelecendo urna 
fundagào sòlida de entendimento comum para o projeto e a construgào do sistema. 

Nuseibeh & Easterbrook (2000) propòem um conjunto bàsico de cinco 
atividades para o processo de engenharia de requisitos: eliciagào, anàlise e 
modelagem, comunicagào, concordància e evolugào dos requisitos. 

Existem diversas maneiras de organizar as atividades dentro do processo de 
engenharia de requisitos, dependendo do tipo de sistema a ser desenvolvido, da 
cultura da organizacional e do nivel de experiència da equipe de desenvolvimento. 
Nào existe um unico processo de engenharia de requisitos que atenda a todas as 
organizagòes. Cada organizagào deve desenvolver o seu pròprio processo, 
adequado as suas caracteristicas e necessidades. Para Kotonya & Sommerville 
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(1998) o processo de engenharia de requisitos é composto pelas atividades de 
eliciagào, anàlise, negociagào e validagào dos requisitos, organizadas conforme 
indicado na Figura 5. 
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Figura 5 - Atividades do processo de engenharia de Requisitos (Kotonya & Sommerville, 98) 


Entretanto o processo de engenharia de requisitos nào é linear. Alteragòes nos 
requisitos sào percebidas e devem ser tratadas de forma interativa durante o 
processo de engenharia de requisitos, corno mostra a Figura 6 (Kotonya & 
Sommerville, 1998) (Boehm, 1988). 
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Figura 6 - Modelo espirai para os processos da engenharia de requisitos (Kotonya & 

Sommerville, 98) 

Corri o objetivo de completar o entendimento do processo de engenharia de 
requisitos, a Figura 7 apresenta o modelo definido por Dym & Little (2000) para o 
processo de engenharia de design de sistemas, onde a preocupagào com requisitos 
se estende para as demais etapas do desenvolvimento do sistema. 
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Figura 7 - Modelo do processo de design (Dym & Little, 2000) 

Analisando-se as diversas abordagens para o tratamento de processos de 
engenharia de requisitos, observa-se que as atividades propostas sào semelhantes 
e complementares, com algumas diferengas de nomenclatura e sequència de 
utilizagào das atividades no processo. No entanto, sera considerado para este 
trabalho, que a abordagem proposta por Kotonya & Sommerville (1998) fornece urna 
visào adequada para estas atividades. 

2.4.3 Eliciagào, anàlise e negociagào de requisitos 

A eliciagào de requisitos compreende o conjunto de atividades que a equipe de 
desenvolvimento utiliza para descobrir as solicitagòes dos stakeholders, buscando 
traduzir as reais necessidades escondidas nestas solicitagòes. As necessidades, 
expectativas e recursos esperados do sistema serào levantados junto a cada 
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stakeholder. Também é necessàrio analisar os requisitos em relagào a 
inconsistèncias e pontos incompletos, bem corno negociar, solucionando conflitos, 
de forma que um conjunto de requisitos sejam acordados. O objetivo é delimitar um 
conjunto de requisitos documentados e priorizados que atendam às reais 
necessidades dos stakeholders. 

A eliciagào dos requisitos està associada ao processo de descoberta e anàlise 
do problema a ser resolvido, detectando o grau de importància de cada stakeholder 
e suas reais necessidades associadas ao problema, além de entender as restrigóes 
impostas ao sistema. Para està anàlise a eliciagào de requisitos deve ser abordada 
por quatro dimensóes (Kotonya & Sommerville, 1998): 

• Entendimento do dominio da aplicagào: compreensào geral da àrea onde o 

sistema é aplicado. 

• Entendimento do problema: compreensào de detalhes do problema onde o 

sistema serà utilizado, através da especializagào do conhecimento geral 

estabelecido para o dominio do problema. 

• Entendimento do negócio: compreensào de corno o sistema interage, afeta e 

contribuì para os objetivos de negócio da organizagào. 

• Entendimento das necessidades e restrigóes: compreensào dos processos de 

traballio que o sistema pretende suportar e às regras a que estarà sujeito. 

As atividades de eliciagào, anàlise e negociagào dos requisitos podem ser 
entendidas corno processos interligados e interativos, representados por urna espirai 
de atividades que converge para a estabilizagào dos requisitos retratados no 
documento de requisitos (Kotonya & Sommerville, 1998). 

O processo de eliciagào de requisitos apresenta quatro atividades bàsicas: 
ajuste dos objetivos da organizagào, aquisigào de conhecimentos bàsicos do 
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sistema, entendimento da organizagào e coleta de requisitos. A Figura 8 apresenta 
um modelo genèrico para o processo de eliciagào de requisitos (Kotonya & 
Sommerville, 1998). 
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Figura 8 - Processo de eliciamo de requisitos (Kotonya & Sommerville, 1998) 

O documento preliminar de requisitos é refinado através da execugào das 
atividades do processo de anàlise de requisitos. A Figura 9 apresenta as atividades 
de forma linear, entretanto estas atividades sào intercaladas no tempo (Kotonya & 
Sommerville, 1998). As atividades de verificagào realizadas no processo de anàlise 
sào: verificagào das necessidades, verificagào de consistència e integridade e 


verificagào de viabilidade. 
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Anàlise dos requisitos 



Negociagào dos requisitos 


Figura 9 - Processo de anàlise e negociagào dos requisitos (Kotonya & Sommerville, 1998) 

A selegào da tècnica adequada para a eliciagào dos requisitos depende do 
tempo e dos recursos disponiveis à equipe de desenvolvimento e do tipo de sistema. 
As técnicas de eliciagào podem ser agrupadas em classes (Nuseibeh & Easterbrook, 
2000 ): 

• Técnicas tradicionais: baseadas na utilizagào de técnicas genéricas para coleta 

de dados e informagòes corno questionàrios, entrevistas e a anàlise da 
documentagào existente. 

• Eliciagào em grupo: baseada no envolvimento dos stakehoiders, explorando 

dinàmicas de grupo para favorecer o entendimento das necessidades. Inclui 
técnicas de brainstorming e reuniées de RAD e JAD 9 (Maiden & Rugg, 1996). 


9 RAD Rapid Application Development e JAD Joint Application Design 
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• Prototipagào: geralmente é utilizada està tècnica quando existem muitas 

incertezas quanto aos requisitos, ou quando é necessàrio que a 
realimentagào do stakeholder seja antecipada. Um protòtipo pode ser utilizado 
para apoiar outras técnicas de eliciagào corno fomentador de discussòes e 
para esclarecimento de dùvidas de funcionamento. 

• Dirigida a modelo: fornece um modelo especifico para cada tipo de informagào 

a ser tratada e utiliza este modelo para direcionar o processo de eliciagào. 
Inclui métodos de modelagem baseados em objetivos, corno KAOS (Van 
Lamsweerde et al, 1998) e I* (Alencar et al, 2000), e métodos de modelagem 
baseados em cenàrios (Maiden et al, 1999). 

• Cognitiva: baseada em técnicas de aquisigào de conhecimento destinadas a 

sistema baseados em conhecimento (Shaw & Gaines, 1996). 

• Contextuais: alternativa para as técnicas tradicionais e cognitivas, baseada em 

técnicas etnogràficas de observagào participante e anàlise de conversagào 
para busca de padróes (Viller & Sommerville, 1999). 

2.4.4 Validagào de requisitos 

Sendo o estàgio final da engenharia de requisitos, a atividade ou processo de 
validagào de requisitos tem corno objetivo estabelecer que os requisitos estejam 
definidos de forma cometa, consistente, integra e precisa. O processo de validagào 
dos requisitos envolve os stakeholders, os engenheiros de requisitos e a equipe de 
design, através da anàlise dos requisitos documentados, buscando problemas, 
omissàes e ambiguidades. 

O principal problema na validagào dos requisitos é que nào hà urna referència 
documentada para ser utilizada corno base na validagào do documento de 
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requisitos. A validagào de requisitos é um processo longo, envolvendo um grupo 
heterogèneo de pessoas que estào tratando um extenso e complexo documento. 

O tratamento da validagào de requisitos corno um processo permite definir 
quais sào as entradas e saidas do processo, bem corno estabelecer um conjunto de 
atividades a serem realizadas dentro do processo (Kotonya & Sommerville, 98). 
Seguem as entradas e saidas associadas ao processo de validagào de requisitos: 

• Documento de requisitos (entrada): versào completa do documento obtida do 

processo de eliciagào, anàlise e negociagào dos requisitos e acordado com os 
stakeholders. O documento é organizado e formatado de acordo com os 
padròes da organizagào. 

• Padròes organizacionais (entrada): o processo de validagào deve estar em 

conformidade com as regras e padròes da organizagào onde o sistema sera 
implantado. 

• Conhecimento organizacional (entrada): as pessoas envolvidas com a 

validagào dos requisitos devem conhecer a organizagào, suas 
particularidades, terminologias, pràticas, capacitagòes individuais e coletivas. 

• Lista de problemas (salda): lista de problemas obtida corno resultado do 

tratamento das entradas do processo de validagào. 

• Lista de agòes (saida): lista de agòes obtida em resposta aos problemas 

encontrados nos requisitos durante o processo de validagào. 

As atividades do processo podem ser organizadas de acordo com diversas 
técnicas, que podem ser aplicadas individualmente ou de forma conjunta, 
dependendo da necessidade. A atividade de validagào de requisitos é a ùltima 
atividade para certificar-se de que o documento de requisitos satisfaz as 
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necessidades dos stakeholders. Vàrias sào as técnicas empregadas (Kotonya & 
Sommerville, 98): 

• Revisòes dos requisitosi é urna das alternativas mais utilizadas no processo de 

validagào. Consiste na revisào dos requisitos por um grupo de pessoas que 
analisam, discutem e propòem alternativas para solucionar os eventuais 
problemas encontrados. A partir dessas descobertas, pode-se adotar medidas 
que solucionem os conflitos. Problemas tipicos encontrados nas revisòes 
incluem: requisitos incompletos, ambiguidade, redundància, falha na 
rastreabilidade e nào obediència a padròes da organizagào. 

• Validagào de modelos: o documento de requisitos pode estar descrito em 

linguagem naturai e também em diagramas ou modelos. Os modelos 
normalmente desenvolvidos sào: modelos de fluxo de dados, modelo de 
objetos, modelos de eventos e modelos de dados. Estes modelos sào 
validados para demonstrar que cada um é consistente, que os modelos do 
sistema estào consistentes entre si e que representam precisamente os 
requisitos dos stakeholders. 

• Prototipagào: A tècnica de prototipagào geralmente é utilizada para auxiliar as 

atividades de eliciagào e anàlise de requisitos, entretanto, pode ser 
empregada também na validagào dos requisitos, onde o protòtipo pode ser 
aperfeigoado com as informagòes do documento de requisitos final e utilizado 
para a validagào junto aos stakeholders. Os protótipos sào desenvolvidos com 
o intuito de permitir urna melhor representagào dos requisitos de um sistema, 
permitindo que o usuàrio tenha urna idéia antecipada de corno o sistema 


funcionarà. 
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• Teste de requisitosi um atributo desejàvel para um requisito é que este possa 
se testado. Deve ser possivel definir um ou mais testes que, quando 
aplicados ao sistema final desenvolvido, possam claramente demonstrar que 
o requisito foi atendido pelo sistema. A dificuldade em definir e propor casos 
de teste adequados pode indicar problemas na definigào dos requisitos. A 
proposigào de casos de teste atua corno um instrumento de validagào 
identificando problemas nos requisitos. 

2.4.5 Gerenciamento de requisitos 

Leffingwell & Widrig (2000) propòem um processo para gerenciamento da 
engenharia de requisitos baseado na formagào adequada das equipes de 
desenvolvimento, que atuam de forma coordenada, em que a base apresenta os 
requisitos do sistema, sustentando as caracteristicas que atendem às necessidades 
dos stakeholders. As equipes sào agrupadas por capacitalo para realizar as 
seguintes atividades: 

1. Anàlise do problema: que compreende a anàlise do problema, modelagem de 

negócio e engenharia de sistemas. 

2. Entendimento das necessidades dos stakeholders : onde ocorre a eliciagào dos 

requisitos, com a utilizagào de diversas técnicas para enderegar os problemas 
e entender as necessidades dos stakeholders. 

3. Definigào do sistema: trata da definigào de um sistema que atenda às 

necessidades dos stakeholders. 

4. Gerenciamento do escopo: tratando o gerenciamento do escopo do projeto que 

està representado na especificagào dos requisitos. 
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5. Refinamento da definigào do sistema: trata da elaboralo dos requisitos para 

obtengào de um grau de detalhe adequado para as etapas de design e 
implementagào. 

6. Construgào do sistema: trata da construgào do sistema que atenda aos 

requisitos especificados, permitindo validagào junto aos stakeholders e 
garantindo a rastreabilidade dos requisitos. 

Para Pressman (2006) o gerenciamento de requisitos é um conjunto de 
atividades que auxiliam a equipe de desenvolvimento a identificar, controlar e 
rastrear requisitos e alteragòes em requisitos, dentro do ciclo de vida do projeto. 
Após a identificagào os requisitos sào incluidos em tabelas de rastreamento que os 
relacionam a um ou mais aspectos do sistema ou ambiente, corno caracteristicas 
dos requisitos, fonte de obtengào do requisito, dependència com os demais 
requisitos, associagào com sub-sistemas e relagào com interfaces do sistema. 

Para Kotonya & Sommerville (1998) o gerenciamento de requisitos é um 
processo de gestào das mudangas ocorridas nos requisitos do sistema, decorrentes 
da melhor compreensào das reais necessidades, por parte dos stakeholders, dentro 
da evolugào do ciclo de vida do projeto e das alteragòes no pròprio ambiente onde o 
sistema està inserido. O processo de gerenciamento de requisitos possui très pontos 
principais: 

• Gerenciar os requisitos acordados. 

• Gerenciar as relagòes existentes entre os requisitos. 

• Gerenciar as dependèncias entre o documento de requisitos e os demais 

documentos produzidos durante o ciclo de vida do projeto. 

As mudangas nos requisitos sào inevitàveis, pois tanto o entendimento do 
sistema por parte dos stakeholders, corno os ambientes politico, organizacional e 
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tècnico onde o sistema està inserido, evoluem com o andamento do 
desenvolvimento do sistema. Neste contexto, agòes de gerenciamento devem ser 
tomadas nào somente durante o processo de engenharia de requisitos, mas durante 
todo o ciclo de vida do sistema. Cada requisito deve ser identificado unicamente, 
oferecendo recursos para o tratamento da rastreabilidade dos requisitos e permitindo 
avaliar o impacto decorrente das mudangas em vàrios niveis. Quando o volume de 
requisitos é muito grande, o que ocorre no desenvolvimento de grandes sistemas, a 
utilizagào de ferramentas de controle e utilizagào de banco de dados passa a ser 
indispensàvel, tanto para armazenar os requisitos corno para controlar o 
relacionamento entre eles (Kotonya & Sommerville, 1998). 

2.4.6 Métodos para engenharia de requisitos 

A engenharia de requisitos é aplicada geralmente em um contexto de relagòes 
e atividades humanas, pressupondo a utilizagào de um sistema computadorizado e 
que possivelmente causarà mudangas nas atividades por eie suportadas. 
Consequentemente, a engenharia de requisitos deve ser sensivel à forma corno as 
pessoas estào inseridas no mundo e corno o trabalho afeta suas agòes. A 
engenharia de requisitos utiliza as cièncias cognitivas e sociais para fornecer 
fundamento teòrico e técnicas pràticas para eliciar e modelar requisitos (Nuseibeh & 
Easterbrook, 2000): 

• Psicologia cognitiva fornece o entendimento das dificuldades que as pessoas 

podem ter em descrever as suas necessidades. 

• Antropologia fornece urna aproximagào metodològica para observar as 

atividades humanas auxiliando na compreensào de corno os sistemas podem 
ajudar ou atrapalhar as pessoas. 
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• Sociologia fornece urna compreensào das mudangas polfticas e culturais 

causadas pela informatizagào. A introdugào de um sistema novo muda a 
natureza do traballio realizado dentro de urna organizagào, pode afetar a 
estrutura e os meios de comunicagào dentro dessa organizagào, podendo até 
alterar os objetivos originais das organizagàes. 

• Linguistica é fundamental jà que a engenharia de requisitos é sustentada por 

comunicagào. As anàlises linguisticas mudaram a forma corno a linguagem 
naturai é utilizada nas especificagàes, buscando evitar ambiguidades e 
melhorar a compreensào. 

Os métodos de engenharia de requisitos sào utilizados para auxiliar o processo 
de eliciagào, estruturagào e formatagào dos requisitos do sistema, sendo urna forma 
sistemàtica para a produgào de modelos do sistema (Kotonya & Sommerville, 1998). 

A modelagem de requisitos auxilia no entendimento da informagào, da fungào e 
do comportamento de um sistema, tornando a anàlise de requisitos mais fàcil e mais 
sistemàtica; fornece o principal instrumento para a revisào de requisitos, 
influenciando na determinagào da completude, consistència e precisào da 
especificagào; e é a referència para as demais etapas do projeto de 
desenvolvimento do sistema (Alencar, 1999). 

Segundo Kotonya & Sommerville (1998) nào existe um mètodo ideal para a 
engenharia de requisitos, pois poucos, ou nenhum, possuem todos os atributos 
necessàrios. Os principais métodos e técnicas de engenharia de requisitos sào: 
modelagem de fluxo de dados, modelagem semàntica, modelagem orientada a 
objetos, modelagem formai, SADT ( Structured Analysis and Design Technique), 
CORE ( Controlled Requirement Expression), VOSE ( Viewpoint-oriented System 
Engineering ) e VORD ( Viewpoint-oriented System Definition). 
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2.5 SYSML 

SysML ( Systems Modeling Language ) (OMGSysML, 2006) é urna linguagem 
gràfica de modelagem de sistemas para uso geral. SysML permite a modelagem de 
sistemas e arquiteturas de produtos, bem corno seus comportamentos e 
funcionalidades, baseada na experiència adquirida na disciplina de engenharia de 
software em construir arquitetura de software em UML (Balmelli, 2006). 

SysML é o resultado de urna iniciativa comum da OMG ( Object Management 
Group) (OMG, 2007) e do IN COSE ( The International Council on Systems 
Engineering) (INCOSE, 2007) para criar urna linguagem unificada de modelagem de 
sistemas que atendesse à requisigào de proposta da OMG, “UML for Systems 
Engineering RFP' (OMGRFP, 2003) doravante denominada apenas RFP 10 , cujo 
objetivo foi a submissào de urna especificagào de personalizagào da UML para 
atender as necessidades da engenharia de sistemas. 

Baseada em urna linguagem gràfica, SysML suporta a especificagào, a anàlise, 
o projeto, a verificagào e a validagào de um grande conjunto de sistemas complexos 
e heterogèneos, nào necessariamente baseados em software, e suportando a 
modelagem de sistemas integrando hardware, software, dados, pessoas, 
procedimentos, processos e infra-estrutura (Vanderperren, 2005) (OMGSysML, 
2006). 

As empresas que desenvolvem sistemas estào sendo pressionadas pelo 
mercado e pelos concorrentes a melhorar a eficiència de seus projetos e sistemas 
de produgào. Analisando o ciclo de vida do produto, observa-se urna falta de 
eficiència na fase conceitual, durante a qual sào decididas as questèes associadas à 

10 Request for Proposai ou solicitagào de proposta 
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arquitetura funcional. A fase conceitual segue a transformagào das necessidades 
dos clientes em fungào do produto e casos de uso, e precede o estàgio de design 
destas fungàes através das diversas disciplinas da engenharia, corno elétrica, 
mecànica e software. SysML foi projetada para mitigar os riscos e os desafios 
encontrados durante a fase conceitual do produto (Balmelli, 2006): 

• Tratando de forma mais eficiente a realizagào dos requisitos em fungàes a 

serem desempenhadas pelo produto; 

• Fornecendo urna representagào formai dos conceitos do sistema e urna 

sustentagào adequada para a tomada de decisào quanto viabilidade do 
produto. 

Semelhante ao obtido com UML quanto à unificagào de urna linguagem para 
modelagem de software, SysML pretende unificar as diversas linguagens utilizadas 
pelos engenheiros de sistemas para a modelagem de sistemas (OMGSysML, 2006). 

SysML é urna extensào da UML versào 2.0. Os diagramas de Màquina de 
Estado ( State Machines), de Interagào ( Interactions ) e de Casos de Uso ( Use Cases ) 
sào reutilizados da UML sem modificagàes, os diagramas de Atividade ( Activities ) e 
de Blocos ( Blocks ) sào reutilizados de UML e estendidos em SysML, e finalmente, 
os diagramas de Requisitos ( Requirements ), de Paràmetros ( Parametrics ) e de 
Alocagào ( Allocation ) sào novos e disponiveis apenas em SysML (Figura 10) 
(Balmelli, 2006). 
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Figura 10 - Comparagao entre UML 2.0 e SysML 1.0 (OMGSysML, 2006) 


SysML utiliza XMI 11 (OMG XML Metadata Interchange) (OMG, 2007) para 
trocar dados de modelagem entre ferramentas e também é compativel com padrào 
ISO 10303-233 (ISO, 07) destinado ao intercambio dos dados na Engenharia de 
Sistemas (OMGSysML, 2006) (Peak, 2007a). 

2.5.1 UML for System Engineering RFP 

Sendo a SysML resultado do atendimento de um processo de requisigào de 
proposta, neste trabalho serào abordados alguns itens do documento RFP, visando 
urna melhor compreensào dos conceitos associados à linguagem SysML. 

O processo completo de urna RFP - Request for Proposai ou Requisigào de 
Proposta permite avaliar e comparar propostas oferecidas pelos fornecedores, 
através do envio, a alguns fornecedores selecionados, de um documento que defina 
precisamente quais atividades devem ser desempenhadas pelo sistema, produto ou 


11 


XMI (XML Metadata Interchange) 
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servilo ofertado, todos os prazos envolvidos, a equipe de traballio necessària, o 
grau de detalhamento a ser utilizado e, principalmente, as consequèncias de um 
eminente fracasso. As propostas recebidas dos fornecedores sào validadas, 
comparadas e avaliadas, permitindo que a empresa selecione a proposta mais 
adequada, sempre através de um mètodo objetivo e preciso (Cundiff, 1997) (Bosik, 
1997). 

A RFP solicita o desenvolvimento de urna linguagem baseada em UML e que 
atenda às necessidades da Engenharia de Sistemas (SE), suportando a modelagem 
de diversos tipos de sistemas complexos e compostos pelos mais variados 
elementos corno: hardware, software, dados, pessoas, procedimentos e infra- 
estrutura. 

A RFP utiliza o termo “UML para Engenharia de Sistema” para referenciar o 
produto obtido com as respostas a RFP e que sera substituido neste trabalho 
apenas pelo termo SysML, visando a simplificar o texto e facilitar o entendimento. 

A RFP define que a SysML deve suportar a anàlise, a especificagào, o projeto 
e a verificagào de sistemas complexos, permitindo (OMGRFP, 03): 

• capturar a informagào dos sistemas de urna maneira precisa e eficiente, 

permitindo a integragào e reutilizagào em larga escala; 

• analisar e avaliar o sistema que està sendo especificado, para identificar e 

resolver os exigèncias de requisitos e design do sistema e para suportar sua 

evolugào; 

• comunicar as informagòes do sistema de forma cometa e consistente aos vàrios 

tipos de stakeholders e participantes do projeto. 

A SysML deve suportar a troca de informagòes entre as fases de anàlise, 
especificagào, design e verificagào existentes em um projeto de desenvolvimento de 
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sistemas, usando urna notagào padronizada e urna semàntica precisa e consistente, 
melhorando a comunicagào entre os participantes do processo de desenvolvimento 
do sistema e promovendo a interoperabilidade entre as ferramentas que suportam 
este processo. A nova linguagem pode também estabelecer urna estrutura padrào 
de modelagem, podendo ser personalizada para necessidades especificas 
(OMGRFP, 03). 

A RFP define que a nova linguagem deve ser obtida através dos mecanismos 
de extensào providos pela UML, combinados com os mecanismos da MOF ( Meta - 
Object Family ) (OMGMOF, 2007). A nova linguagem deve manter o relacionamento 
e a compatibilidade com as evolugòes das especificagées da OMG. 

A RFP està estruturada em seis capitulos e dois apèndices, dos quais pode ser 
destacado o capitulo dois, que estabelece contexto arquitetural baseado na MDA 
(Model Driven Architecture ) da OMG (OMGMDA, 2007) (Harmon, 2004). O capitulo 
seis, “Requisitos Especificos da Proposta”, também merece destaque, pois 
estabelece diretamente os requisitos a serem atendidos pela SysML 1.0. Os 
requisitos obrigatórios da RFP representam o nucleo bàsico das necessidades da 
Engenharia de Sistemas e devem ser atendidos na versào inicial da nova linguagem, 
SysML 1.0. Os requisitos obrigatórios estào organizados em elementos para 
modelagem de sistemas e foram agrupados nas seguintes categorias: estrutura, 
comportamento, propriedades, requisitos, verificagào e complementares (OMGRFP, 
2003). 

2.5.2 Diagramas SysML 

SysML utiliza urna variedade de diagramas (Figura 11) semanticamente 
fundamentados e que permitem a representagào de sistemas complexos. SysML 
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modifica algumas construgèes existentes em UML e adiciona outras especificas para 
o tratamento das necessidades da engenharia de sistemas (OMG, 2007). Os 
diagramas estào agrupados em très categorias: estrutura, comportamento e 
requisitos. 



Figura 11 - Tipos de Diagramas da SysML (OMGSysML, 2006) 


O bioco é o elemento bàsico para a representagào da estrutura do sistema em 
SysML e pode ser utilizado para representar hardware, software, instalagèes, 
pessoas, ou outro elemento do sistema. A estrutura do sistema é representada pelo 
diagramas de definigào de bioco e pelo diagrama de bioco interno. O diagrama de 
definigào de bioco descreve a hierarquia do sistema e a classificagào dos sistemas e 
componentes. 

O diagrama de caso do uso, o diagrama de atividade, o diagrama de sequència 
e o diagrama da màquina do estado formam o conjunto de diagramas utilizados para 
representar o comportamento do sistema. O diagrama de caso de uso fornece urna 
descrigào de alto nivel das funcionalidades do sistema. O diagrama de atividade 
representa o fluxo dos dados e o controle existente entre as atividades realizadas 
pelo sistema. Um diagrama de sequència representa a interagào entre partes 
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colaborativas de um sistema. O diagrama de màquina de estado descreve as 
transigées de estado e as agées que um sistema, ou suas partes, executam em 
resposta aos eventos. 

O diagrama de requisito permite representar os requisitos, geralmente 
expressos em linguagem texto, através de elementos gràficos, além de permitir 
também relacionar estes requisitos a outros elementos do modelo do sistema. O 
diagrama de requisito representa as hierarquias e derivagòes existentes nos 
requisitos, permitindo também associar um determinado requisito a outro modelo 
que està tratando a sua satisfagào e verificagào. O diagrama de requisito prove urna 
ponte entre as ferramentas tipicas de gerenciamento de requisitos e os modelos do 
sistema. 

O diagrama de paràmetro representa as restrigòes impostas ao sistema tais 
corno desempenho, confiabilidade e propriedades fisicas. Atua corno meio de 
integragào das especificagées e modelos de design com os modelos de anàlise da 
engenharia. 

SysML também oferece um relacionamento de alocagào que pode ser utilizado 
para alocar um conjunto de elementos de modelagem a outro, permitindo relacionar 
um comportamento à estrutura ou alocar lògica a componentes fisicos. A alocagào 
permite diversos tipos de relacionamento entre modelos de fases diferentes do 
desenvolvimento do projeto, corno por exemplo: a ligagào entre os requisitos e os 
elementos de design ; o mapeamento do comportamento nas estruturas de 
implementagào; e, também, a associagào de partes do software com o 
desenvolvimento do hardware (OMGSysML, 2006). 
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2.5.3 Ferramentas de modelagem 

Sendo SysML urna linguagem gràfica, a utilizagào de urna ferramenta CASE 12 
proporciona o apoio adequado às atividades de modelagem, visualizagào e 
gerenciamento dos diversos diagramas oferecidos pela linguagem. Existem diversos 
fornecedores no mercado que oferecem ferramentas CASE com recursos para 
modelagem em UML 2 e que podem ser estendidas para suportar também a 
modelagem em SysML. O site oficial da OMG SysML 13 apresenta alguns destes 
fornecedores: 

• ARTiSAN Software Tools: o Artisan Studio é a ferramenta para 
modelagem UML oferecida pela empresa e suporta a modelagem 
tanto em UML 2 corno em SysML (ARTISAN, 2008). 

• EmbeddedPlus Engineering: é urna empresa associada à IBM que 
oferece o EmbeddedPlus SysML Toolkit , urna extensào para as 
ferramentas de modelagem da IBM Rational 14 (EmbeddedPlus, 2008). 

• No Magic: o MagicDraw é a ferramenta para modelagem UML 
oferecida pela empresa e suporta a modelagem tanto em UML 2 corno 
em SysML (NoMagic, 2008). 

• Papyrus: oferece a ferramenta de código aberto para modelagem 
gràfica em UML 2, o Papyrus 4 UML e urna extensào para tratamento 
SysML (Papyrus, 2008). 


12 Computer-aided software engineering 

13 OMG Systems Modeling Language, site oficial na internet: http://www.omqsvsml.org/ 

14 IBM Rational Software Modeler - RSM, IBM Rational Software Architect - RSA e IBM Rational 
Systems Developer - RSD (IBMRational, 2008). 
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2.5.4 Anàlise da SysML 1.0 

SysML é urna linguagem para modelagem de um dominio especifico, a 
Engenharia de Sistemas, e definida corno urna personalizagào da UML 2.0 que, por 
sua vez, é urna linguagem de modelagem para uso geral. A vantagem em definir 
SysML corno urna personalizagào da UML é a reutilizagào da notagào e a da 
semàntica da UML, ambas relativamente maduras. Entretanto, SysML também 
herda alguns problemas inerentes à UML, corno a complexidade de notagào e 
semàntica e falhas no padrào de interoperabilidade entre diagrama, XMI (XML 
Metadata Interchange). (SysMLForum, 2007). 

Urna das maiores evolugbes encontradas em SysML, em relagào à UML, é a 
possibilidade de representagào de requisitos e de relacionà-los tanto com o modelo 
do sistema, corno com a modelagem do design e com os procedimentos de teste 
(Vanderperren, 2005). 

SysML é menor e mais fàcil de aprender que UML, pois nào possui as 
construgòes dedicadas ao tratamento de software e apresenta um numero reduzido 
de tipos de diagrama. SysMI possui apenas nove diagramas em comparagào aos 
treze existentes em UML (SysMLForum, 2007). 

O racional, urna extensào de comentàrio utilizada em SysML, permite registrar 
as informagòes associadas a decisbes em geral, principalmente decisoes de design. 
Um racional pode ser ligado a qualquer entidade ou relacionamento, permitindo, por 
exemplo, associar elementos de design com requisitos, capturando e registrando o 
embasamento utilizado para urna determinada decisào de design, auxiliando a 
anàlise do impacto de urna alteragào de requisitos no design do sistema 
(OMGSysML, 2006). 
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SysML introduz o diagrama de requisitos e define diversos tipos de 
relacionamentos para melhorar o rastreamento de requisitos. A finalidade nào é 
substituir as ferramentas comerciais de gerència de requisitos, mas fornecer urna 
maneira padronizada para associar os requisitos ao design e teste. Os requisitos 
podem ser decompostos através da utilizagào do relacionamento de contengào, 
similar a forma utilizada em diagramas da classe. A dependència nomeada corno 
rastreamento relaciona um determinado requisito derivado ao seu requisito origem. 
O design do sistema e os requisitos sào ligados através da dependència satisfagào. 
Finalmente, a dependència verificagào associa um requisito com um caso de teste, 
utilizado para verificar estes requisitos. O diagrama de requisito contribuì para a 
rigorosa transferència das especificagòes e informagèes relacionadas ao sistema 
entre as diversas ferramentas utilizadas pelos engenheiros de sistema, software e 
hardware (Vanderperren, 2005). 

SysML introduz o conceito de montagem, um estereótipo de classe que 
descreve um sistema corno urna estrutura de partes interconectada. Montagem 
fornece um elemento neutro de modelagem que pode ser utilizado para representar 
qualquer tipo de sistema, independentemente da natureza de seus componentes. 
Um modelo de montagem mostra a interconexào das partes de um sistema e 
suporta fluxos de informagào entre os componentes (Vanderperren & Dehaene, 
2005). 

A introdugào do conceito de alocagào em SysML, provè um recurso genèrico 
para relacionar um elemento de modelo a elementos de outro modelo. Além disso, 
causa o abandono do diagrama de comunicagào e do diagrama de impiantalo 
existentes na UML. O conceito de alocagào em SysML nào està restrito apenas a 
alocagào de artefatos de software aos componentes de hardware. Permite, também, 
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por exemplo, a ligagào entre os requisitos e os elementos de design e o 
mapeamento do comportamento nas estruturas de implementagào. 

SysML introduz o conceito de controle de operagào nos diagramas de 
atividades, o qual permite controlar a execugào das atividades, Inabilitando ou 
desabilitando agòes em fungào dos dados e paràmetros, sendo que em UML o 
controle permite apenas indicar quando urna agào se inicia (OMGSysML, 2006). 

Paràmetros nào fazem parte da UML e foram introduzidos corno novo recurso 
em SysML, permitindo aos engenheiros de sistema representar e analisar as 
diversas restrigòes impostas ao sistema, tais corno desempenho, confiabilidade e 
propriedades fisicas. A anàlise é urna fase critica na engenharia de sistemas, 
entretanto diversas linguagens que antecedem SysML, corno UML e IDEF (IDEF, 
2007), nào resolvem de forma padronizada o problema de relacionar os requisitos e 
a especificagào do sistema com os elementos de design produzidos na fase de 
anàlise. Os paràmetros de SysML permitem tratar este problema de forma 
padronizada, através de très elementos de modelagem: restrigòes, propriedades e 
paràmetros propriamente ditos. Restrigòes sào anàlogas a fórmulas de equagòes. 
Um bioco de restrigòes é urna definigào de formula que pode ser reutilizada e urna 
propriedade de restrigào é um uso particular de um bioco genèrico de restrigào. 
Propriedades representam os valores associados a qualquer caracteristica de um 
ambiente, sistema ou componente utilizado na anàlise do sistema. Paràmetros sào 
as variàveis associadas a urna equagào, ou restrigào. Cabe observar que SysML 
nào executa diretamente estas restrigòes, propriedades e paràmetros, os quais sào 
passados para outras ferramentas de anàlise para serem computados (Peak, 2007a) 
(Peak, 2007b) (OMGSysML, 2006). 
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A SysML 1.0 nào atende pienamente todos os requisitos da RFP. A matriz de 
conformidade dos requisitos (OMGSysML, 2006) possui um conjunto de requisitos 
obrigatórios parcialmente atendidos e alguns requisitos obrigatórios nào atendidos, e 
que estào planejados para a versào 2.0. O mesmo ocorre com os requisitos 
opcionais. 

M. Frapier e H. Habrias, no livro “Software Specification Methods: An OverView 
Using a Case Study", 2000, apresentam um processo para comparar, sem a 
intengào de classificagào, métodos de especificagào de software, (Frapier & Habrias, 
00). Os atributos a serem avaliados na anàlise dos métodos de especificagào estào 
apresentados na Tabela 3. 


Tabela 3 - Atributos para anàlise dos métodos (Frapier & Habrias, 00) 


# 

Atributo 

Yalores 

1 

Paradigma 

state machine, algebra, process algebra, 
trace 

2 

Formalismo 

Informai, semi-formal, formai 

3 

Representagào gràfica 

Sim, nào 

4 

Orientagào objetos 

Sim, nào 

5 

Concorrència 

Sim, nào 

6 

Executabilidade 

Sim, nào 

7 

Uso de variàveis 

Sim, nào 

8 

Nào determinismo 

Sim, nào 

9 

Lògica 

Sim, nào 

10 

Provabilidade 

Sim, nào 

11 

Verificagào de modelo 

Sim, nào 

12 

Inibigào de evento 

Sim, nào 


A Tabela 4 apresenta a anàlise realizada pelo autor deste trabalho sobre a 
linguagem SysML 1.0 tornando corno referència os atributos do processo de 
comparagào de Frappier, onde se pode constatar que SysML atende a grande parte 
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dos atributos, tende a ser formai quando os requisitos da RFP forem atendidos e 
conta com um conjunto de profissionais potencialmente treinados na sua utilizagào 
pois é urna extensào de UML 2. 

Tabela 4 - Anàlise da SysML 1 .0 


# 

ktributo 

SysML 

Comentàrio 

1 

Paradigma 

state machine 

Heranga de UML através do 
diagrama de màquina de 
estado. 

2 

Formalismo 

Formai e semi- 
forma 1 

0 conceito de alocagào, a 
revisào dos diagramas 

herdados de UML e suas 
extensòes favorecem as 

anàlises sintàticas, léxicas e 
semànticas livre de contexto. 
Entretanto os requisitos 

obrigatórios da RFP (OMGRFP, 
03) nào sào totalmente 
atendidos na versào 1.0 da 
SysML 

3 

Representagào 

gràfica 

Sim 

Heranga da UML 

4 

Orientagào objetos 

Sim 

Heranga da UML 

5 

Concorrència 

Sim 

Heranga da UML 

6 

Executabilidade 

Sim 

Os conceitos de controle de 
operagào e de paràmetros 
oferecem recursos para 

simulagào de alguns 

diagramas 

7 

Uso de variàveis 

Sim 

Paràmetros 

8 

Nào determinismo 

Sim 

Paràmetros (fórmulas) 

9 

Lògica 

nào 


10 

Provabilidade 

nào 


11 

Verificagào de 

modelo 

Sim 

Entretanto SysML 1.0 nào 
atende pienamente a RFP 

12 

Inibigào de evento 

Sim 

Viabilizado pela introdugào 
dos conceitos de controle de 
operagào e paràmetros. 
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3 PROPOSTA DE MÈTODO PARA GESTÀO DE REQUISITOS 

Este trabalho propóe um conjunto de atividades para a gestào de requisitos de 
sistemas, baseado em técnicas do escopo de engenharia de processos de negócio, 
de engenharia de requisitos, no processo unificado de desenvolvimento de software 
e na utilizagào de linguagens formais de modelagem, que seja aplicàvel pelos 
analistas de negócio e pelos engenheiros de requisitos e que agilize o processo de 
aceitagào das especificagóes dos sistemas de informagào por parte dos 
stakeholders, denominado neste estudo de Mètodo para Gestào de Requisitos. 

O Mètodo para Gestào de Requisitos propóe processos que permitam a 
utilizagào da modelagem orientada a objetos e da linguagem UML versào 2, tanto na 
modelagem da visào da engenharia de requisitos, corno na modelagem da visào da 
engenharia de processos de negócio, que serào executados, preferencialmente, por 
equipes independentes e possivelmente em diferentes janelas de tempo. Em ambas 
as visóes, este trabalho propóe processos de gestào que viabilizem a transformagào 
da modelagem em UML versào 2 para a linguagem formai de modelagem SysML. O 
Mètodo para Gestào de Requisitos pretende obter urna visào unificada das 
modelagens formais dos requisitos e dos processos de negócio e que serà utilizada, 
após as revisóes e iteragóes necessàrias, no tratamento da aceitagào da 
especificagào dos requisitos do sistema junto aos stakeholders. 

A Figura 12 è urna representagào gràfica do mètodo proposto e auxilia um 
melhor entendimento dos processos que compóem o mètodo, representando 
também a comunicagào entre eles. Os retàngulos com os cantos arredondados 
representam as etapas ou atividades de trabalho, os losangos representam tomadas 
de decisào, as setas direcionais cheias representam o fluxo bàsico das etapas de 
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trabalho e as setas direcionais tracejadas indicam a comunicagào associada ao 
tratamento da gestào dos requisitos do sistema. 



A coluna da esquerda apresenta as atividades associadas à Visào da 
Engenharia de Requisitos (VI), onde o objetivo é a eliciagào e especificagào dos 
requisitos do sistema, realizadas pela equipe de engenheiros de requisitos. A coluna 
da direita apresenta as atividades associadas à Visào da Engenharia de Processos 
de Negócio (V2), onde o objetivo é a modelagem de negócio associada ao sistema 
solicitado, realizadas pela equipe de analistas de negócio. A coluna centrai 
concentra as atividades de gestào e controle dos requisitos do sistema (V3), onde a 
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equipe de gestào do projeto atua desde a solicitagào do sistema a ser desenvolvido 
até a fase final de aceitagào dos requisitos do sistema junto aos stakeholders, 
direcionando a sincronizagào adequada das demais atividades que compòem o 
mètodo de gestào de requisitos proposto. 

3.1 VISÀO DA ENGENHARIA DE REQUISITOS (VI) 

A Visào da Engenharia de Requisitos (VI) da Figura 12, neste estudo, é 
realizada através das seguintes atividades bàsicas: 

• Eliciagào e Anàlise dos Requisitos do Sistema (Al . 1 ): atividade que recebe os 

dados associados ao contrato firmado na Solicitagào do Sistema (A3.1) e, ao 
final do processo iterativo de negociagào com os stakeholders fornece corno 
salda um conjunto de requisitos documentados e priorizados do sistema que 
atendam às reais necessidades dos stakeholders. 

• Especificagào Preliminar dos Requisitos em UML 2 (Al. 2): atividade que 

recebe os requisitos do sistema documentados e priorizados e, ao final do 
processo iterativo de negociagào com os stakeholders, fornece corno salda a 
modelagem dos requisitos do sistema representados na linguagem UML 2. 

• Modelagem Formai dos Requisitos em SysML (Al. 3): atividade que recebe a 

modelagem de requisitos do sistema em UML 2 corno entrada e, ao final do 
processo iterativo de negociagào com os stakeholders, fornece corno salda a 
modelagem dos requisitos do sistema solicitado representado na linguagem 
formai SysML. 
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3.1.1 Eliciagào e Anàlise dos Requisitos do Sistema (A1.1) 

A eliciagào de requisitos compreende o conjunto de atividades que a equipe 
formada por engenheiros de requisitos utiliza para levantar as solicitagòes dos 
stakeholders, buscando traduzir as reais necessidades nestas solicitagòes. As 
necessidades, expectativas e recursos esperados do sistema serào levantados junto 
a cada stakeholder. Também é necessàrio analisar os requisitos em relagào a 
inconsistèncias e pontos incompletos, bem corno negociar, solucionando conflitos, 
de forma que um conjunto de requisitos seja acordado. O objetivo é delimitar um 
conjunto de requisitos priorizados que atendam às reais necessidades dos 
stakeholders e estejam registrados no Documento de Requisitos. 

A eliciagào dos requisitos està associada ao processo de descoberta e anàlise 
do problema a ser resolvido, detectando o grau de importància de cada stakeholder 
e suas reais necessidades associadas ao problema, além de entender as restrigòes 
impostas ao sistema, devendo ser abordada por quatro dimensòes: entendimento do 
dominio da aplicagào, entendimento do problema, entendimento do negócio e 
entendimento das necessidades e restrigòes. 

O processo de eliciagào de requisitos apresenta quatro atividades bàsicas: 
ajuste dos objetivos da organizagào, aquisigào de conhecimentos bàsicos do 
sistema, entendimento da organizagào e coleta de requisitos. 

O Documento Requisitos é refinado através da execugào das atividades do 
processo de anàlise de requisitos, representadas pelas atividades: verificagào das 
necessidades, verificagào de viabilidade e verificagào de consistència e integridade. 

Os resultados obtidos nesta atividade sào registrados no Documento de 
Requisitos que contém a especificagào de requisitos do sistema e é formado pelos 


artefatos: 
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• Modelo de casos de uso. 

• Descrigào dos casos de uso. 

• Especificagóes suplementares. 

A equipe de engenheiros de requisito deve realizar as atividades associadas à 
eliciagào e a anàlise dos requisitos do sistema, sempre sob a supervisào da equipe 
de gestào para garantir a sincronizagào com os processos de negócio. Està 
sincronizagào é obtida através de: 

• Aplicagào de padróes na utilizalo de nomes dos elementos de 
modelagem, com a utilizagào de vocabolàrio ùnico e dicionàrio de 
nomes. 

• Compartilhamento de dados e informagòes obtidas junto aos 
stakeholders. 

• Otimizagào no acesso, entrevistas e reuniòes com os stakeholders. 

O resultado desta etapa do trabalho é apresentado pela equipe de engenheiros 
de requisitos aos stakeholders em reuniào formai para validagào e negociagào do 
conteùdo, da qual participam também a equipe de gestào para tratamento de escopo 
e sincronizagào com o tratamento dos processos de negócio. Eventualmente està 
atividade pode indicar a necessidade de revisào dos requisitos, desencadeando um 
processo iterativo onde as alteragòes sào negociadas com os stakeholders. 

3.1.2 Especificagào Preliminar dos Requisitos em UML2 (Al .2) 

Da atividade de Eliciagào e Anàlise dos Requisitos (A1.1) resulta o modelo de 
casos de uso e a especificagào suplementar de requisitos do sistema, representados 
em parte de forma textual, oferecendo urna visào dos requisitos do sistema a ser 


desenvolvido. 
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Nesta etapa do traballio, a equipe de traballio formada por engenheiros de 
requisitos trabalha o Documento de Requisitos para que este esteja representado 
em UML 2, utilizando os diversos recursos e diagramas oferecidos pela linguagem, 
tais corno: diagrama de casos de uso, diagrama de sequència, diagrama de 
atividades e diagrama de màquina de estado. O objetivo é representar os requisitos 
no diagrama de casos de uso e nos diagramas de atividades associados a estes 
casos de uso. Os demais diagramas sào utilizados pela equipe para auxiliar a 
eliciagào dos requisitos e, muitas vezes, chegam a representar detalhes de design e 
implementagào visando a esclarecer os requisitos e aumentar a compreensào das 
necessidades dos stakeholders. 

Os requisitos nào-funcionais definidos no documento de especificagàes 
suplementares devem ser refinados e detalhados e serào utilizados na etapa de 
Modelagem Formai dos Requisitos em SysML (Al .3). 

O resultado desta etapa do trabalho é apresentado pela equipe de engenheiros 
de requisitos aos stakeholders em reuniào formai para validagào e negociagào do 
conteùdo, da qual participam também a equipe de gestào para tratamento de escopo 
e sincronizagào com o tratamento dos processos de negócio. Eventualmente està 
atividade pode indicar a necessidade de revisào dos requisitos, desencadeando um 
processo iterativo onde as alteragòes sào negociadas com os stakeholders. 

3.1.3 Modelagem Formai dos Requisitos em SysML (Al .3) 

A atividade de Especificagào Preliminar dos Requisitos em UML 2 (Al .2) 
resulta em diversos diagramas representando os requisitos e as necessidades dos 
stakeholders quanto ao sistema e, possivelmente, detalhes adicionais que auxiliaram 
a tarefa de eliciagào dos requisitos. 
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SysML é urna extensào da UML versào 2.0, onde o diagrama de casos de uso 
é reutilizado da UML 2 e o diagrama de atividade de SysML é obtido através da 
extensào do diagrama de atividades da UML 2.0. 

Nesta etapa do trabalho, a equipe formada por engenheiros de requisitos deve 
transferir o diagrama de casos de uso e os diagramas de atividades associados aos 
casos de uso representados em UML 2 para SysML, os demais diagramas utilizados 
em UML 2 foram utilizados apenas para auxiliar a eliciagào dos requisitos. 

Utilizando a ferramenta de modelagem UML 2.0, os engenheiros de requisitos 
exportam os diagramas para arquivos XML, os quais sào importados na ferramenta 
de modelagem SysML. Os diagramas de casos de uso importados podem ser 
tratados diretamente na ferramenta de modelagem SysML. Os diagramas de 
atividades importados podem ser retrabalhados pela equipe de trabalho para 
incorporar as extensòes de SysML que permitem controlar a execugào das 
atividades, habilitando ou desabilitando agòes em fungào de dados e paràmetros, 
sendo que em UML o controle permite apenas indicar quando urna agào se inicia. 

A equipe de trabalho formada por engenheiros de requisitos utiliza o diagrama 
de requisitos de SysML para representar os requisitos nào-funcionais descritos no 
documento de especificagàes suplementares. 

O resultado desta etapa do trabalho é apresentado pela equipe de engenheiros 
de requisitos aos stakeholders em reuniào formai para validagào e negociagào do 
conteùdo, da qual participam também a equipe de gestào para tratamento de escopo 
e sincronizagào com o tratamento dos processos de negócio. Eventualmente, està 
atividade pode indicar a necessidade de revisào dos requisitos, desencadeando um 
processo iterativo onde as alteragòes sào negociadas com os stakeholders. 
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3.2 VISÀO DA ENGENHARIA DE PROCESSOS DE NEGÓCIO (V2) 

A Visào da Engenharia de Processos de Negócio (V2) da Figura 12, neste 
estudo, é realizada através das seguintes atividades bàsicas: 

• Modelagem dos Processos de Negócio (A2.1): atividade que recebe os dados 

associados ao contrato firmado na Solicitagào do Sistema (A3.1) e, ao final do 
processo iterativo de negociagào com os stakeholders, fornece corno salda 
urna visào ampia da modelagem dos processos de negócio da empresa, 
tendo corno foco principal os processos de negócio associados ao sistema 
solicitado. 

• Especificagào Preliminar da Modelagem de Negócio em UML 2 (A2.2): 

atividade que recebe a modelagem dos processos de negócio da empresa e, 
ao final do processo iterativo de negociagào com os stakeholders, fornece 
corno salda a modelagem dos processos de negócio da empresa em UML 2, 
com ènfase para os requisitos de negócio associados ao sistema solicitado. 

• Modelagem Formai dos Requisitos de Negócio em SysML (A2.3): atividade que 

recebe a modelagem de negócio em UML 2 corno entrada e, ao final do 
processo iterativo de negociagào com os stakeholders, fornece corno salda a 
modelagem dos requisitos de negócio associados ao sistema solicitado 
representado na linguagem formai SysML. 

3.2.1 Modelagem dos Processos de Negócio (A2.1) 

Nesta etapa a equipe de trabalho formada por analistas de negócio deve 
levantar e documentar os objetivos, processos e recursos do negócio, considerando 
as oportunidades de melhoria associadas aos processos de negócio atuais, para 
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que estes possam ser remodelados numa situagào futura e para que, a partir deles, 
possam ser derivados os casos de uso de negócio. Sempre sob a supervisào da 
equipe de gestào para garantir a sincronizagào dos processos de negócio com o 
foco do traballio que é o tratamento dos requisitos do sistema a ser desenvolvido, a 
equipe de analistas de negócio deve realizar os seguintes passos: 

1. Capturar um vocabolàrio de negócio comum que possa ser utilizado em 
todas as descrigóes textuais do negócio. 

2. Identificar os objetivos da organizagào corno um todo e, através de 
desdobramentos hieràrquicos, obter sub-objetivos mais detalhados, 
permitindo a rastreabilidade dos objetivos estratégicos até os objetivos 
operacionais. 

3. Identificar e modelar os processos de negócio atuais, descrevendo a 
sequència de atividades que devem ser executadas em cada processo, 
para se alcangar os objetivos definidos anteriormente. Além disso, o 
analista de negócio também deve identificar e modelar os recursos 
(sistemas, unidades organizacionais responsàveis e informagóes de 
entrada e salda) que serào necessàrios para a execugào dos processos 
de negócio. 

4. Associar os objetivos identificados aos processos de negócio que irào 
suportà-los, onde os relacionamentos entre objetivos e processos 
podem ser: um para um, um para muitos e muitos para muitos. 

5. Identificar as necessidades de melhorias nos processos de negócio, 
identificando e priorizando os principais problemas. 

6. Modelar os novos processos e, caso necessàrio, os novos recursos que 
serào implantados para a execugào do negócio. 
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7. Identificar os casos de uso de negócio associados aos processos de 
negócio. A derivagào dos casos de uso dos processos de negócio pode 
ser urna relagào um para muitos. Desta forma, um processo ou urna 
atividade de um processo, dependendo do nivel de detalhamento em 
que estejam modelados, pode gerar apenas um ou vàrios casos de uso. 

O resultado obtido na modelagem dos processos de negócio é o diagrama de 
casos de uso de negócio, onde a descrigào do fluxo de traballio relacionado a um 
processo de negócio pode ocorrer de duas formas: 

• Representagào textual com a utilizagào de um formato bàsico de 
descrigào, descrevendo o fluxo normal e os fluxos alternativos. 

• Utilizagào do diagrama de atividades, descrevendo graficamente os 
passos do caso de uso de negócio. 

O nivel de detalhe adequado para identificagào e descrigào dos casos de uso 
de negócio, bem corno a padronizagào da nomenclatura a ser utilizada nos 
elementos que compóem a modelagem sào definidos pelo analista de negócio e 
pela equipe de gestào do projeto. 

O resultado desta etapa do trabalho é apresentado pela equipe de analista de 
negócio aos stakeholders, em reuniào formai para validagào e negociagào do 
conteùdo, da qual participam também a equipe de gestào para tratamento de escopo 
e sincronizagào com o tratamento dos requisitos do sistema a ser desenvolvido. 
Eventualmente, està atividade pode indicar a necessidade de revisào dos processos 
de negócio, desencadeando um processo iterativo onde as alteragóes sào 
negociadas com os stakeholders. 
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3.2.2 Especificagào Preliminar Modelagem de Negócio UML 2 (A2.2) 

A atividade de Modelagem dos Processos de Negócio (A2.1) resultou o 
diagrama de casos de uso de negócio, formado pelos casos de uso de negócio e a 
descrigào dos fluxos de traballio de forma textual ou utilizando o diagrama de 
atividades, oferecendo urna visào dos processos de negócio onde o sistema a ser 
desenvolvido està contido. 

O diagrama de atividades, dentre os diagramas da UML 2, é o que mais se 
aproxima dos modelos tradicionais de modelagem de processos de negócio. Dessa 
forma, esse tipo de diagrama, inicialmente concebido com o intuito de modelar o 
fluxo de trabalho relacionado ao comportamento de um sistema, também pode ser 
utilizado para modelagem de processos de negócio, podendo ser denominado de 
diagrama de atividades de negócio. 

Assim corno os demais diagramas tradicionais utilizados para modelagem de 
processos de negócio, esse diagrama permite modelar o fluxo de trabalho 
considerando situagóes de sincronismo e de decisào; permite relacionar, através de 
colunas, papéis e unidades organizacionais responsàveis pela execugào das 
atividades do processo; e também pode mostrar, através de extensòes da UML 2, os 
comportamentos e relacionamentos entre as entidades de negócio e as atividades 
em execugào. 

Nesta etapa do trabalho, a equipe formada por analistas de negócio deve 
priorizar os casos de uso de negócio, tendo corno foco os requisitos do sistema a ser 
desenvolvido, eliminar toda representagào textual utilizada para a descrigào dos 
fluxos de trabalho nos casos de uso de negócio e obter um modelo de casos de uso 
de negócio representado em UML 2. Sempre sob a supervisào da equipe de gestào 
para garantir a sincronizagào dos processos de negócio com o foco do trabalho que 
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é o tratamento dos requisitos do sistema a ser desenvolvido, a equipe de analistas 
de negócio deve realizar os seguintes passos: 

1. Priorizar os casos de uso de negócio que oferecem requisitos para o 
sistema a ser desenvolvido, com a orientagào da equipe de gestào e 
mantendo o sincronismo com o tratamento de requisitos do sistema. 

2. Retrabalhar os casos de uso de negócio, com representagào textual dos 
fluxos de traballio, para que estes sejam representados no diagrama de 
atividades da UML 2. 

3. Elaborar o diagrama de casos de uso de negócio em UML 2, tendo 
corno foco o tratamento de requisitos do sistema. 

A priorizagào dos casos de uso de negócio é orientada pela equipe de gestào 
de projetos, mantendo a sincronizagào dos processos de negócio com o foco do 
trabalho que é o tratamento dos requisitos do sistema a ser desenvolvido. 

O resultado desta etapa do trabalho é apresentado pela equipe de analista de 
negócio aos stakeholders em reuniào formai para validagào e negociagào do 
conteùdo, da qual participam também a equipe de gestào para tratamento de escopo 
e sincronizagào com o tratamento dos requisitos do sistema a ser desenvolvido. 
Eventualmente està atividade pode indicar a necessidade de revisào dos processos 
de negócio, desencadeando um processo iterativo onde as alteragóes sào 
negociadas com os stakeholders. 

3.2.3 Modelagem Formai dos Requisitos de Negócio em SysML (A2.3) 

A atividade de especificagào preliminar da modelagem dos Processos de 
Negócio em UML 2 (A2.2) resulta o diagrama de casos de uso de negócio e os 
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diagramas de atividade associados aos fluxos de trabalho, corri ènfase para os 
requisitos de negócio associados ao sistema a ser desenvolvido. 

SysML é urna extensào da UML versào 2.0, onde o diagrama de casos de uso 
é reutilizado da UML 2 e o diagrama de atividade de SysML é obtido através da 
extensào do diagrama de atividades da UML 2.0. 

Nesta etapa do trabalho, a equipe de trabalho, formada por analistas de 
negócio, deve transferir o diagrama de casos de uso de negócio e os diagramas de 
atividades em UML 2 para SysML. 

Utilizando a ferramenta de modelagem UML 2.0, os analistas de negócio 
exportam os diagramas para arquivos XML e estes sào importados na ferramenta de 
modelagem SysML. Os diagramas de casos de uso importados podem ser tratados 
diretamente na ferramenta de modelagem SysML. Os diagramas de atividades 
importados podem ser retrabalhados pelos analistas de negócio para incorporarem 
as extensoes de SysML, que permitem controlar a execugào das atividades, 
habilitando ou desabilitando agóes em fungào de dados e paràmetros. Em UML o 
controle permite apenas indicar quando urna agào inicia. 

Ainda nesta etapa, os analistas de negócio, auxiliados por engenheiros de 
requisitos da equipe de gestào do projeto, tornando corno referència diagrama de 
casos de uso de negócio e os diagramas de atividades, realizam urna estimativa dos 
requisitos para o sistema a ser desenvolvido, através da criagào de um modelo de 
casos de uso do sistema. A realizagào do modelo de casos de usos do sistema é 
feita através dos seguintes passos: 

• Verificar se um ator de negócio utilizarà o sistema e, em caso afirmativo, 
criar um ator para o sistema no modelo de casos de uso do sistema com 
o mesmo nome do ator de negócio. 
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• Para cada caso de uso de negócios em que o ator de negócio, que foi 
incluido no modelo de casos de uso do sistema, criar um caso de uso de 
sistema. 

• Repetir estes passos para todos os atores de negócio. 

O resultado desta etapa do trabalho é apresentado pela equipe de analista de 
negócio aos stakeholders, em reuniào formai para validagào e negociagào do 
conteùdo, da qual participam também a equipe de gestào para tratamento de escopo 
e sincronizagào com o tratamento dos requisitos do sistema a ser desenvolvido. 
Eventualmente està atividade pode indicar a necessidade de revisào dos processos 
de negócio, desencadeando um processo iterativo onde as alteragóes sào 
negociadas com os stakeholders. 

3.3 GESTÀO DOS REQUISITOS DO SISTEMA (V3) 

Este estudo propóe que a Gestào dos Requisitos do Sistema (V3) da Figura 12, 
seja realizada através das seguintes atividades bàsicas: 

• Solicitagào do Sistema (A3. 1 ): atividade que representa a iniciagào do projeto, 

estabelecendo o contrato firmado junto aos stakeholders para o 
desenvolvimento do sistema e definigào do escopo e das restrigóes iniciais do 
sistema. 

• Sincronizagào Gerencial de Conteùdo (A3. 2): atividade realizada pela equipe 

de gestào do projeto atuando na formagào e capacitalo adequada das 
equipes, na comunicagào entre as equipes de engenharia de requisitos e 
processos de negócio, e na utilizalo adequada dos insumos e artefatos 
parciais obtidos por estas equipes. 
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• Consolidagào dos Requisitos Alinhados corri Negócio (A3. 3): atividade 

realizada por representantes das equipes de engenharia de requisitos e 
processos de negócio, onde ocorre a sincronizagào entre o modelo em SysML 
obtido na visào da engenharia de requisitos e o modelo em SysML obtido na 
visào da engenharia de processos de negócio. 

• Validagào dos Requisitos do Sistema (A3. 4): atividade que recebe a 

consolidagào dos requisitos alinhados com o negócio modelados em SysML e 
que através de um processo iterativo de negociagào, o qual tem a 
participagào de stakeholders, analistas de negócio, engenheiros de requisitos 
e equipe de design, fornece corno salda a modelagem formai dos requisitos 
do sistema representada em SysML, alinhada com os processos de negócio 
da empresa e validada pelos stakeholders. 

• Aceitagào dos Requisitos do Sistema em SysML (A3. 5): atividade que recebe a 

modelagem formai dos requisitos do sistema em SysML, fornecendo para a 
negociagào de aceitagào dos requisitos junto aos stakeholders a possibilidade 
de rastrear cada um dos requisitos dentro dos processos de engenharia de 
requisitos e de engenharia de processos de negócio. Està atividade fornece 
corno saida a modelagem formai dos requisitos do sistema, definindo o 
escopo do projeto de desenvolvimento e oferecendo insumos adequados para 
as estimativas de tamanho e esforgo. 

3.3.1 Solicitagào do Sistema (A3. 1) 

Atividade que representa a iniciagào do projeto, estabelecendo o contrato 
firmado junto aos stakeholders para o desenvolvimento do sistema e definindo o 
escopo e as restrigóes iniciais do sistema. 
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Nesta etapa do traballio sào realizadas as seguintes atividades: 

• Preparar o ambiente para o projeto, avallando o projeto e a organizagào, 
selecionando ferramentas e decidindo quais partes do processo devem 
ser melhoradas. 

• Obter e documentar urna descrigào inicial do sistema a ser 
desenvolvido. A descrigào do sistema terà menos detalhes nas fases 
iniciais do projeto e mais detalhes nas fases finais, urna vez que as 
caracteristicas do sistema sào progressivamente elaboradas nas demais 
etapas. 

• Atingir o consenso entre a equipe de gestào de projetos e os 
stakeholders sobre os objetivos do ciclo de vida do projeto, indicando os 
resultados obtidos a cada etapa e o grau de comprometimento esperado 
dos stakeholders. 

• Obter e organizar a documentagào jà existente na organizagào e que 
sera utilizada corno insumo para as etapas seguintes. 

• Tratar o planejamento de alocagào das equipes de trabalho, tanto para o 
tratamento da visào da engenharia de processos de negócio formada 
por analistas de negocio, corno para o tratamento da visào da 
engenharia de requisitos, formada por engenheiros de requisitos. 

• Treinar a equipe de trabalho para a cometa utilizagào dos métodos, 
técnicas e ferramentas a serem utilizados. 

• Analisar a possivel defasagem de tempo entre o tratamento da visào da 
engenharia de processos de negócio e o tratamento da visào da 
engenharia de requisitos, permitindo planejar a sincronizagào dos 
trabalhos e a consolidagào dos resultados. 
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Està etapa fornece o material de entrada e estrutura os recursos necessàrios 
para a realizagào das atividades associadas à Visào da Engenharia de Requisitos 
(VI) e à Visào da Engenharia de Processos de Negócio (V3), além de preparar a 
equipe de trabalho e recursos necessàrios para as demais atividades da gestào de 
requisitos do sistema. 

3.3.2 Sincronizagào Gerencial de Conteudo (A3. 2) 

A atividade de Solicitagào do Sistema (A3.1) fornece o material de entrada, os 
direcionadores de trabalho e o planejamento de recursos necessàrios para a 
realizagào das atividades associadas à visào da engenharia de requisitos e à visào 
da engenharia de processos de negócio. 

Nesta atividade é proposto que a equipe de gestào atue na manutengào da 
comunicagào e sincronizagào dos resultados obtidos pelas duas visóes, realizando 
as seguintes atividades: 

• Manter o ambiente de trabalho através da manutengào das ferramentas 
de trabalho, incluindo diagramadores UML e SysML, esquemas de 
controle de versào e padronizagào de documentos. 

• Manter o dicionàrio de dados e vocabulàrio. 

• Manter a alocagào das equipes de trabalho, tanto para o tratamento da 
visào da engenharia de processos de negócio formada por analistas de 
negocio, corno para o tratamento da visào da engenharia de requisitos, 
formada por engenheiros de requisitos. 

• Oferecer treinamentos complementares aos integrantes das equipes das 
duas visóes, garantindo a homogeneidade dos trabalhos e padronizagào 


dos resultados. 
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• Tratar a possivel defasagem de tempo entre o tratamento da visào da 
engenharia de processos de negócio e o tratamento da visào da 
engenharia de requisitos, permitindo a sincronizagào dos trabalhos e a 
consolidagào dos resultados. 

• Tratar e gerenciar a gestào de mudangas. 

• Tratar a gestào da comunicagào com os stakeholders, nas duas visóes e 
atuar corno facilitador nesta comunicagào, evitando retrabalhos e 
acessos desnecessàrios e duplicados aos stakeholders. 

Nesta atividade a equipe de gestào atua gerencialmente tanto nas atividades 
Eliciagào e Anàlise de Requisitos (Al . 1 ), Especificagào Preliminar dos Requisitos em 
UML 2 (Al .2) e Modelagem Formai dos Requisitos em SysML (Al. 3), associadas à 
Visào da Engenharia de Requisitos (VI), corno nas atividades Modelagem dos 
Processos de Negócio (A2.1), Especificagào Preliminar da Modelagem de Negócio 
em UML 2 (A2.2) e Modelagem Formai dos Requisitos de Negócio em SysML (A2.3), 
associadas à Visào da Engenharia de Processos de Negócio, garantindo que os 
resultados das atividades (Al. 3) e (A2.3) sejam entregues adequadamente para a 
atividade Consolidagào dos Requisitos Alinhados com o Negócio (A3. 3). 

A eventual defasagem de tempo entre o tratamento da Visào da Engenharia de 
Requisitos (VI) e a Visào da Engenharia de Processos de Negócio (V2), onde as 
atividades A2.1 e A2.2 sào realizadas antecipadamente às atividades A1.1 e Al. 2, 
ou até mesmo nào sào realizadas resultando na inexistència de urna modelagem de 
negócio, a sincronizagào Gerencial do conteùdo deve atuar alocando analistas de 
negócio para obter urna modelagem de negócio que adequada para a realizagào da 
atividade Modelagem Formai dos Requisitos de Negócio em SysML (A2.3). 
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Està etapa garante, através de urna atuagào gerencial, que as atividades 
Modelagem Formai dos Requisitos em SysML (Al .3) e Modelagem Formai dos 
Requisitos de Negócio em SysML (A2.3) sejam realizadas de acordo com as 
definigóes propostas nesta pesquisa, fornecendo os insumos necessàrios para a 
realizagào da atividade de consolidagào dos requisitos alinhados com negócio. 

3.3.3 Consolidagào dos Requisitos Alinhados com Negócio (A3. 3) 

Està atividade deverà ser coordenada pela equipe de gestào e recebe corno 
entrada os modelos em SysML obtidos pela Modelagem Formai dos Requisitos do 
Sistema (Al .3) e Modelagem Formai dos Requisitos de Negócio (A3. 3), resultados 
das atividades associadas, respectivamente, à Visào da Engenharia de Requisitos 
(VI) e à Visào da Engenharia de Processos de Negócio (V3), e fornece um modelo 
ùnico em SysML e consolidado, onde os requisitos do sistema estào em 
concordància com os requisitos de negócio. 

O trabalho realizado na atividade de Sincronizagào Gerencial de Conteùdo 
(A3. 2), busca garantir que os dois modelos representados em SysML estejam 
construidos sob as mesmas regras de padronizagào de nomes, vocabulàrio, 
estrutura de diagramagào dos modelos e relagóes de dependència entre elementos 
dos modelos. 

As ferramentas para diagramagào SysML oferecem recursos para a 
representagào da estrutura dos modelos indicando as dependèncias entre os 
elementos que compoem a linguagem e, também, fornecendo recursos para 
validagào sintètica da construgào dos diagramas e das dependèncias entre eles. 
Estas ferramentas oferecem também recursos baseados na construgào sintètica dos 
modelos listando as diferengas entre dois modelos, que possuem a mesma estrutura 
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de construgào, e orientam na detecgào de inconsistència e falhas nas relagóes de 
dependència entre os elementos. 

A facilidade de verificagào de diferengas sintàticas entre modelos oferece um 
instrumento para a equipe de gestào, auxiliada por analistas de negócio e 
engenheiro de requisitos, detectarem as inconsistèncias entre os dois modelos e 
realimentar tanto a atividade de Modelagem Formai dos Requisitos do Sistema 
(Al. 3), corno a atividade de Modelagem Formai dos Requisitos de Negócio (A2.3), 
para que os modelos evoluam e oferegarm o grau de consistència adequado. 
Permitindo, assim, que seja obtido um modelo unico contemplando as duas visóes e 
contando com as relagóes de dependèncias corretas e consistentes, bem corno 
oferecendo, desta forma, um caminho de rastreabilidade entre os requisitos do 
sistema e os requisitos de negócio atendidos pelo sistema e que estào alinhados 
com o modelo de negócio da organizagào. 

As ferramentas para diagramagào SysML oferecem também recursos para a 
fusào de dois modelos, em que os elementos com mesmo nome e sintaxe sào 
fundidos e relatórios para tratamento de diferengas sào oferecidos permitindo que 
eventuais inconsistèncias entre os modelos possam ser tratadas. Este recurso de 
fusào de modelos permite selecionar dois modelos diferentes e gerar um terceiro, 
representando a fusào dos dois primeiros modelos, obtendo-se, desta forma, um 
modelo de requisitos ùnico, contemplando as necessidades de negócio e que deve 
facilitar o processo de validagào e aceite junto aos stakeholders. 

3.3.4 Validagào dos Requisitos do Sistema em SysML (A3. 4) 

Està atividade tem corno objetivo estabelecer que os requisitos estejam 
definidos de forma cometa, consistente e integra. O processo de validagào dos 
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requisitos envolve os stakeholders, a equipe de gestào, analistas de negócio e 
engenheiros de requisitos. Tem corno objetivo a anàlise do documento de requisitos, 
buscando problemas, omissóes e ambiguidades. Nesta atividade pode haver 
também o envolvimento das equipes de design e implementagào do projeto, com o 
objetivo de detectar eventuais dificuldades de implementagào ou melhorias 
decorrentes de solugòes tecnológicas, fornecendo insumos para aprimoramentos e 
corregòes nos requisitos. 

O principal problema na validagào dos requisitos é que nào ha urna referència 
documentada para ser utilizada corno base na validagào do documento de 
requisitos. A validagào de requisitos é um processo longo, envolvendo um grupo 
heterogèneo de pessoas que estào tratando um extenso e complexo documento. 

A atividade de Consolidagào dos Requisitos Alinhados Negócio (A3. 3) resulta 
em um documento de requisitos representado por um modelo em SysML e obtido 
através da consolidagào dos requisitos do sistema frente aos processos de negócio. 

Nesta etapa, o documento de requisitos sera apresentado pela equipe de 
trabalho aos stakeholders, buscando a validagào dos requisitos, utilizando urna 
documentagào gràfica, de fàcil compreensào e contendo elementos de 
rastreabilidade com os requisitos e processos de negócio da organizagào. Obtém-se, 
assim, um instrumento eficiente para sustentar um processo convergente e ràpido de 
convencimento dos stakeholders quanto à completude e à cobertura dos requisitos 
do sistema a ser desenvolvido. 

O trabalho serà coordenado pela equipe de gestào com a participagào de 
engenheiros de requisitos e analistas de negócio. O resultado do trabalho serà urna 
versào refinada do documento de requisitos e serà apresentado aos stakeholders 
em reuniào formai para validagào e negociagào do conteùdo. Eventualmente està 
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atividade poderà indicar a necessidade de revisào dos requisitos ou até mesmo da 
modelagem de negócio, desencadeando um processo iterativo onde as alteragóes 
sào negociadas com os stakeholders. 

3.3.5 Aceitagào dos Requisitos do Sistema em SysML (A3. 5) 

A atividade Validagào dos Requisitos do Sistema em SysML (A3. 4) fornece o 
documento de requisitos onde os requisitos do sistema estào representados em 
SysML e compativeis com os processos de negócio. 

A equipe de gestào, juntamente com os engenheiros de requisitos, calcularà as 
estimativas de tamanho, esforgo e prazo para o desenvolvimento do sistema. 

O documento de requisitos, junto com as estimativas de tamanho, esforgo e 
prazo, sera apresentado aos stakeholders, com o objetivo de obter o aceite e a 
aprovagào de seu conteùdo. 

O resultado desta atividade sera o documento de requisitos, junto com as 
estimativas de tamanho, esforgo e prazo, aceito e aprovado pelos stakeholders, 
oferecendo às equipes de desenvolvimento um instrumento representado em urna 
linguagem formai, provavelmente reduzindo o volume de interpretagóes semànticas. 
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4 CASOS DE APLICAQÀO DO MÈTODO PROPOSTO 


Este capitulo tem corno objetivo ilustrar o mètodo proposto para gestào de 
requisitos através da apresentagào de dois casos, um associado ao 
desenvolvimento de sistema de informagào e outro ao desenvolvimento de um 
sistema de automagào de màquinas de venda. 

A utilizagào de ferramenta CASE para a modelagem dos processos de negócio 
e dos requisitos oferece recursos para modelagem, visualizagào e gerenciamento 
dos diversos diagramas que compòem o documento de requisitos. Existem diversos 
fornecedores que oferecem ferramentas para modelagem UML 2 e que podem ser 
estendidas para suportar a modelagem em SysML. O site oficial da OMG SysML 15 
apresenta diversos fornecedores: 

• ARTiSAN Software Tools: o Artisan Studio é a ferramenta para 
modelagem UML oferecida pela empresa e suporta a modelagem 
tanto em UML 2 corno em SysML (ARTISAN, 2008). 

• EmbeddedPlus Engineering: é urna empresa associada a IBM que 
oferece o EmbeddedPlus SysML Toolkit, urna extensào para as 
ferramentas de modelagem da IBM Rational 16 (EmbeddedPlus, 2008). 

• No Magic: o MagicDraw é a ferramenta para modelagem UML 
oferecida pela empresa e suporta a modelagem tanto em UML 2 corno 
em SysML (NoMagic, 2008). 


15 OMG Systems Modeling Language, site oficial na internet: http://www.omqsvsml.org/ 

16 IBM Rational Software Modeler - RSM, IBM Rational Software Architect - RSA e IBM Rational 
Systems Developer - RSD (IBMRational, 2008). 
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• Papyrus: oferece a ferramenta de código aberto para modelagem 
gràfica em UML 2, o Papyrus 4 UML, e urna extensào para tratamento 
SysML (Papyrus, 2008). 

A modelagem dos dois casos foi realizada na ferramenta MagicDraw, contando 
com licengas de utilizagào de software temporària fornecida pelo fabricante 
especificamente para o desenvolvimento deste estudo. 

Cabe ressaltar que a descrigào dos casos foi inserida neste trabalho com o 
intuito de melhor explicitar o mètodo proposto e nào pretende demonstrar os 
artefatos gerados, apresentando apenas aqueles mais relevantes. 

4.1 CASO DESENVOLVIMENTO DE SISTEMA DE INFORMAQÀO 

Este caso associado ao desenvolvimento de sistema de informagào foi 
baseado na tese de doutorado apresentada no programa de pós-graduagào da 
Faculdade de Engenharia Mecànica da UNICAMP (Kintschner, 2003) que teve corno 
base um estudo em empresas do setor tèxtil. 

O objetivo de apresentar este caso é discutir, principalmente, as atividades de 
Modelagem Formai dos Requisitos em SysML (Al .3), Modelagem Formai dos 
Requisitos de Negócio (A2.3) e Consolidagào dos Requisitos Alinhados com Negócio 
(A3.3) propostas no Modelo de Gestào de Requisitos da Figura 12. 

Visando a um melhor entendimento do caso de aplicagào sera apresentada 
descrigào do modelo de negócio bàsico associado ao processo tèxtil. 
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4.1.1 Descrigào do Processo tèxtil 

O processo tèxtil consiste de dois processos bàsicos de negócio, a fiagào e a 
tecelagem (Corder, 1994). A Figura 13 apresenta o modelo de casos de uso de 
negócio do processo tèxtil. 



Figura 13 - Processo Tèxtil: Casos de Uso Negócio 

O processo de fiagào è a etapa inicial do processo produtivo tèxtil, que se inicia 
com a obtengào das fibras geradoras, que podem ser do tipo naturai, artificial ou 
sintètica. 

A fiagào consiste na paralelizagào das fibras e na aderència de urna às outras 
por atrito e no torcimento para que adquiram resistència, resultando em fios 
homogèneos preparados para a fabricagào de tecidos. O processo de fiagào para os 
diversos tipos de fibras geradoras è muito parecido. 

A fase de fiagào resulta em fios penteados ou cardados, sendo que a qualidade 
e a regularidade diferenciam os dois tipos. O fio penteado oferece urna melhor 
qualidade devido ao maior nùmero de processos de limpeza a que è submetido, 
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diminuindo a quantidade de residuos nas fibras, e urna melhor regularidade, em 
razào da redugào nas torgòes sofridas, resultando em urna textura mais lisa e 
refinada. Este tipo de fio é indicado para a produgào de tecidos destinados à 
confecgào, corno camisas e lengóis. O fio cardado oferece urna menor qualidade, 
devido ao maior nùmero de torgòes, e é utilizado para a produgào de jeans, tecidos 
para estofados e cortinas entre outros. 

A Figura 14 apresenta o diagrama de atividades do processo de fiagào do fio 
cardado. 


act [Activity] Processo de Fiacao [ £|j Processo de Fiagao ] 



V y 


Figura 14 - Processo de Fiagào: Diagrama de Atividades 
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O processo de tecelagem consiste em dispor os fios que estào enrolados nas 
bobineiras e subdividi-los em urdume e trama. No urdume, os fios sào reunidos em 
paralelo e determinam o comprimente do tecido, pois estào dispostos 
longitudinalmente nos teares e permitem a execugào da trama e produzir o tecido. A 
Figura 15 apresenta o diagrama de atividades do processo de tecelagem. 


act [Activity] Processo de Tecelagem [ ^Processo de Tecelagem ] | 


Estoque Fios 


Tecelagem 


Estoque Tecidos 


1 


Fornecer Fios 



t ^ 

t 

Elaborar Trama Urdir Fios 


ì 

t 

Remeter Fios 


Tecer Fio 


Estocar Tecido 


Figura 15 - Processo de Tecelagem: Diagrama de Atividades 
A atividade Solicitagào do Sistema (A3.1) da Figura 12 representa a iniciagào 
do projeto, estabelecendo o contrato firmado junto aos stakeholders para o 
desenvolvimento do sistema e definindo o escopo e as restrigòes iniciais do sistema, 
que, neste caso, é o desenvolvimento de um sistema de informagào capaz de 
suportar e controlar o processo produtivo associado à linha de produgào do tecido 
jacquard, utilizado geralmente para decoragào. 
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4.1.2 Visào da Engenharia de Processos de Negócio (V2) 

As atividades Modelagem Processos de Negócio (A2.1) e Especificagào 
Preliminar da Modelagem de Negócio em UML 2 (A2.2) da Figura 12, neste caso, 
foram suprimidas e o resultado para a atividade Modelagem Formai dos Requisitos 
de Negócio em SysML (A2.3) està representada pelo diagrama de casos de usos de 
negócio e pelos diagramas de atividades associados aos casos de uso. 

A Figura 16 apresenta o diagrama de casos de uso de negócio associados à 
produgào de tecido jacquard, representando a relagào entre os atores e os casos de 
usos de negócio. 



Figura 16 - Linha de Produgào: Casos de Uso de Negócio 
O caso de uso de negócio controle de fios està detalhado no diagrama de 
atividades da Figura 17, que representa o processo de controle do estoque de fios 
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crus e tingidos e o gerenciamento da entrada e salda de fios para o tingimento em 
empresa terceirizada. 


act [Activity] Controle de Fios [ [^] Controle de Fios ]J 



Figura 17 - Controle de Fios: Diagrama de Atividades 
Segue a descrigào das atividades: 

• Estocar fio algodào: as caixas de fio de algodào cru sào recebidas e 
armazenadas em locai reservado para esse tipo de fio. 

• Estocar fio de polièsteri as caixas de fio de poliéster sào recebidas e 
armazenadas em locai reservado para esse tipo de fio. 

• Verificar necessidade de tingimento de fio: a partir de verificagào do 
ponto minimo no estoque de fios de algodào e poliéster e os novos 
pedidos a serem produzidos, sào definidos os rolos de fios que serào 
enviados para a empresa terceirizada para serem tingidos. 
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• Verificar quebra: para cada retorno de tingimento de fios em empresa 
terceirizada é verificada a diferenga existente entre a quantidade em 
quilos enviada e recebida. 

• Estocar fio tingido: o fio tingido recebido é estocado de tal forma que 
facilite sua manipulagào para envio à produgào. 

• Montar urdume: a partir dos pedidos de venda sào montados os rolos 
urdumes que serào utilizados para a fabricagào dos tecidos. 

O caso de uso controle de produgào de tecido està detalhado no diagrama de 
atividades da Figura 18. 

act [Acti-vt/] Connote ae Pmd-^fo de Tedifo | j^[ Cantrole ite Produco a» Teocto | ) 



Figura 18 - Controle de Produgao de Tecido: Diagrama de Atividades 
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Segue a descrigào das atividades: 

• Receber pedidos de venda: os pedidos de venda sào recebidos via fax 
ou e-mail e sào agrupados semanalmente para definigào de 
programagào de produgào. 

• Planejar produgào: a partir dos pedidos recebidos na semana é definida 
a programagào de produgào de acordo com os artigos, desenhos, cor de 
urdume e cor da trama. 

• Verificar estoque de fios: a partir do planejamento da produgào é 
verificada a quantidade de fios tingidos no estoque e a necessidade de 
envio de fios para fingimento. 

• Programar tear: com a definigào da programagào da produgào e das 
cores dos urdumes a serem utilizados, é definida a programagào dos 
teares disponiveis. 

• Fabricar tecido. o urdume é engrupado e a trama é montada no tear, 
permitindo a fabricagào do tecido a partir destes dois fios. 

• Revisar tecido. o tecido produzido é revisado para verificar se houve 
algum defeito na produgào. 

• Estocar tecido acabado. o rolo de tecido acabado é revisado e é 
estocado até sua expedigào. 

O caso de uso de negócio controle de fingimento de fios està detalhado no 
diagrama de atividades da Figura 19, representando o processo de fingimento, 
que é realizado em empresa terceirizada. 
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•et lAdrvty) Camole de Tirqrranto oc Fio»[ ^ Cedro te de Tngmenlo de Fos )j 



Figura 19 - Controle de Tingimento de Fios: Diagrama de Atividades 
Segue a descrigào das atividades: 

• Programar màquina: corri o recebimento da listagem de lotes a serem 
tingidos, é realizada a conferència da lista, com a verificagào da 
prioridade da produgào e da existència da receita de tingimento. Quando 
do infoio da prepararlo do processo de tingimento, é iniciado o 
preenchimento do formulàrio de acompanhamento do processo de 
tinturaria (FAPT), que sera completado no decorrer do processo. 
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• Pesar lote cru: as rocas de fios que irào ser tingidos sào pesadas. Sào 
preenchidas no FAPT as seguintes informagòes: total de quilos do lote e 
o nome do funcionàrio que realizou a pesagem. 

• Inspecionar e prensar: os fios sào colocados em cestos e inspecionados 
visualmente e em seguida sào prensados. Sào preenchidos no FAPT: 
nùmero da prensa, nùmero do cesto e nome do funcionàrio que realizou 
o traballio. 

• Checar receita: este procedimento é realizado quando nào hà receita 
relacionada com a programagào do tingimento ou quando hà mais de 
dois meses està cor nào é utilizada. 

• Preparar corante: sào separados e pesados os corantes que serào 
utilizados e, em seguida, preparada a receita. 

• Tingir fio: os cestos sào transportados para a màquina de tingimento e, 
em seguida, sào colocados os corantes. Durante o tingimento, o 
funcionàrio faz verificagàes relativas ao PH e à pressào. O processo de 
tingimento leva em mèdia de duas a très horas. Sào preenchidos no 
FAPT: nùmero da màquina, PH tingimento, PH redugào, PH amaciante, 
pressào, data do tingimento e o nome do funcionàrio que executou o 
tingimento. 

• Secar: após o tingimento, os cestos sào levados para a màquina de 
secagem. Sào preenchidos no FAPT: hora infoio da secagem, hora firn 
da secagem e o funcionàrio que realizou a secagem. 

• Verificar qualidade: após a secagem, sào retiradas e analisadas 
amostras de très rolos do lote. Caso estejam dentro do padrào, o lote è 
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liberado para embalagem. Caso seja detectado algum problema, sào 
retiradas mais amostras e enviadas para o laboratòrio. 

• Embalar: após a liberagào, as rocas sào embaladas e enviadas para a 
expedigào. 

Tornando corno referència o diagrama de casos de uso de negócio e os 
diagramas de atividades, a Figura 20 apresenta urna estimativa dos requisitos para o 
sistema de informagào obtidos da Visào da Engenharia de Negócio (V2). 



Figura 20 - Estimativa para os requisitos do sistema 
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4.1.3 Visào da Engenharia de Requisitos (VI) 

As atividades Eliciagào e Anàlise de Requisitos (A1.1) e Especificagào 
Preliminar dos Requisitos em UML 2 (Al .2) da Figura 12, neste caso, foram 
suprimidas e o resultado para a atividade Modelagem Formai dos Requisitos em 
SysML (Al. 3) està representado pelo diagrama de casos de uso e pelo diagrama de 
requisitos. 

A Figura 21 apresenta o diagrama de casos de uso associados ao sistema de 
informagào para suporte e controle da linha de produgào do tecido jacquard. 



Figura 21 - Requisitos funcionais: Diagrama de Casos de Uso 
Segue a descrigào de cada caso de uso do sistema: 

• Receber pedido de venda: trata do cadastro do pedido de venda do 
cliente informando: CNPJ, nome e enderego (rua, cidade, estado, 
telefone, fax, e-mail) do cliente, artigo (desenho, cor urdume, cor trama), 
quantidade, data do pedido e data provàvel para entrega. 
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• Estocar fios: trata do recebimento das caixas de fios no almoxarifado e 
para cada recebimento é informado o fornecedor, lote do fornecedor, 
data de produgào, nùmero da nota fiscal, peso bruto, peso liquido e 
quantidade de rocas. 

• Verificar quebra: trata da verificagào de quebra e consiste em gerenciar 
a quantidade de fios recebidos que apresentam quebras. Deve ser 
informado: tipo de fio, data do envio, saldo do fio em estoque, saldo 
acumulado enviado, quantidade de saida, nùmero da nota fiscal de 
referència, data do recebimento, cor, peso da entrada, peso da quebra, 
nùmero da nota fiscal referència. 

• Estocar tecido acabado: o sistema sugere locai de armazenagem do 
tecido (almoxarifado e quadra) até a expedigào do mesmo, sendo 
permitido ao almoxarife trocar o locai definido. 

• Planejar produgào: os pedidos de venda sào agrupados semanalmente 
por desenho, cor de urdume e cor da trama. O resultado desta atividade 
é um relatório informando a quantidade de pegas que deverào ser 
produzidas na semana. 

• Programar tear: a partir do planejamento da produgào é definido o que 
deverà ser produzido em cada tear, através do agrupamento por cor do 
urdume, pois esse é o item com maior dificuldade de ser alterado em um 
tear. A ficha de programagào do tear gerada tem as seguintes 
informagèes: nùmero do tear, nome do artigo, data, cor, quantidade 
(pegas) e observagào. 
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• Montar urdume: trata do preenchimento do formulàrio de fabricagào do 
rolo de urdume com as seguintes informagòes: numero do rolo de 
urdume, nùmeros dos lotes dos fios, quantidade de fios, peso, metros do 
rolo e data de fabricagào do rolo. 

• Fabricar tecido: com a fabricagào do tecido a partir do rolo de urdume e 
das rocas de trama sào gravadas as seguintes informagSes sobre o rolo 
de tecido: cliente, data de produgào, lote de rocas utilizadas de trama, 
lote de rolo de urdume utilizado, metragem produzida, peso da pepa 
produzida. 

• Revisar tecido: trata da verificagào da qualidade do tecido, que só sera 
liberado se estiver de acordo com o padrào. Caso o tecido nào seja 
liberado sera informado o problema ocorrido e o tecido fica bloqueado 
até a resolugào do problema. 

• Gerenciar Usuàrios Sistema: trata do cadastro e controle de acesso dos 
usuàrios do sistema. 

A Figura 22 apresenta o diagrama de requisitos onde os requisitos nào 


funcionais estào modelados. 
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req [Model] Requisitos Nào Funcionais[ IfL; Requisitos Nào Funcionais ] 


«requirement» 

Identidade Visual Ùnica 


«requirement» 

Tempo de Resposta 
interior a 3s 



«requirement» qj 

Multi-lingua 


«requirement» qj 

Atender NBR 17799 






«requirement» qj 

Usuàrio novato e 
experiente 


«requirement» qj 

Treinamento bàsico 
atinge 60% sistema 





«requirement» 

Software Livre coni 
liceità GPL 


«requirement» 

lndica 9 ao Operaio 
em Andamento 


Figura 22 - Requisitos nào funcionais: Diagrama de Requisitos 


4.1.4 Visào da Gestao de Requisitos do Sistema (V3) 

A atividade de Solicitagào do Sistema (A3.1) da Figura 12 estabeleceu o 
contrato com os stakeholders para o desenvolvimento do sistema de informagào 
para suporte e controle da linha de produgào do tecido jacquard. 

Na atividade Sincronizagào Gerencial de Conteùdo (A3. 2) foram mantidas as 
ferramentas de trabalho, o controle de versóes, a padronizagào de documentos e o 
dicionàrio de dados e vocabulàrio utilizados na Visào da Engenharia de Requisitos 
(VI) e na Visào da Engenharia de Processos de Negócio (V2). 

Na atividade Consolidagào dos Requisitos Alinhados com Negócio (A3. 3) os 
resultados obtidos na Visào da Engenharia de Requisitos (VI) e na Visào da 
Engenharia de Processos de Negócio (V3) sào comparados com o recurso de 
comparagào de projetos oferecido pela ferramenta de modelagem, cujo resultado 
està apresentado na Figura 23. 


117 



Figura 23 - Diferengas nas visòes de requisitos e negócios 
O lado esquerdo da Figura 23 apresenta os elementos que compóem a Visào 
da Engenharia de Processos de Negócios (V2) e o lado direito os elementos que 
compóem a Visào da Engenharia de Requisitos (VI). 

Considerando-se a legenda da Figura 23, onde a cor cinza indica elementos 
que foram exclufdos, observa-se que o resultado da comparagào apresenta um 
conjunto de casos de uso e um ator do sistema que estào sendo considerados na 
Visào da Engenharia de Processos de Negócios (V2) e que nào estào na Visào da 
Engenharia de Requisitos (VI). Analisando-se estes casos de uso observa-se que o 
caso de uso de negócio Controle de Tingimento de Fios nào foi considerado na VI e 
que deve ser incluido para o desenvolvimento do sistema. 
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Por outro lado, a legenda verde na Figura 23 indica que elementos foram 
inseridos na VI, um caso de uso e um ator, ambos associados ao tratamento do 
controle de acesso ao sistema, e que nào foram considerados na V2. 

O resultado final da atividade Consolidagào dos Requisitos Alinhados com 
Negócio (A3. 3) é a uniào dos modelos de VI e V2, que é obtida com o recurso de 
fusào de projetos oferecido pela ferramenta de modelagem. 

A Figura 24 apresenta a tela intermediària de fusào das visòes VI e V2. 
Necessàrio observar que as agàes a serem executada sobre os elementos estào 
indicadas na legenda e que existe um tratamento para inibir ou efetivar as agòes. A 
marcagào em vermelho inibe a agào e a marcagào em verde efetiva a agào indicada 
na legenda. 
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Figura 24 - Tela de fusào dos projetos 

A finalizagào da fusào das visàes VI e V2 resulta em um modelo contendo a 
modelagem de requisitos do sistema contemplando as necessidades de negócio. A 
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Figura 25 apresenta o modelo de casos de uso do sistema de informagào para 
suporte e controle da linha de produgào do tecido jacquard. 



Figura 25 - Modelo de Casos de Uso do Sistema 
As atividades de Validagào dos Requisitos do Sistema (A3. 4) e Aceitagào dos 
Requisitos do Sistema (A3. 5) sào realizadas tornando corno referència o modelo de 
casos de usos da Figura 25. 
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4.2 DESCRIQÀO DO CASO DE AUTOMAQÀO 

Este caso associado ao desenvolvimento de sistema de automagào foi 
baseado na experiéncia obtida em um projeto reai de urna empresa. Este projeto 
ainda està em andamento e as informagàes apresentadas neste estudo representam 
os resultados obtidos até o momento. 

O objetivo de apresentar este caso é apresentar, de forma parcial, a aplicagào 
do mètodo de gestào de requisitos na especificagào de novos produtos. Estes 
produtos fazem parte da evolugào tecnològica pretendida pela empresa para melhor 
atender seus clientes. Neste caso sera tratado especificamente um produto 
associado ao controle e supervisào de màquina de venda, pretendido e 
encomendado por um cliente especifico. 

4.2.1 Descrigào da Empresa 

A Signalcard Tecnologia Itda é urna empresa que desenvolve e comercializa 
solugàes para automagào de vendas, controle de acesso, tarifagào de servigos e 
transporte pùblico. Grande parte destas solugàes està baseada na utilizagào de 
cartào indutivo, tecnologia desenvolvida pela Signalcard e suportada por diversas 
patentes. 

No cartào indutivo, os dados estào armazenados em células. Cada célula 
possui um pequeno fusivel feito de urna liga metàlica. Como urna memòria de 
computador, é possivel associar códigos a cada célula do cartào, de modo que o 
valor é "1" se a célula estiver continua e "0" se o fusivel foi fundido e, 
consequentemente, a célula estiver interrompida (Figura 26). Normalmente, todas as 
células do cartào sào produzidas com valor "1" e sào gravadas nas unidades de 
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leitura e gravagào de cartào. Està gravagào é ùnica e nào retornàvel, garantindo a 
alta seguranga do cartào indutivo. Além disso, o cartào indutivo nào pode ser 
produzido, copiado ou duplicado fora da indùstria, o que Ihe confere caracteristicas 
anti-fraude com alta relagào custo-beneficio. 

Disposigào interna das células 
indutivas do cartào 


Cada célula 
ou fusivel 


è 



Figura 26 - Estrutura interna do cartào indutivo 
A evolugào dos meios e das redes de comunicagào oferece oportunidades para 
o desenvolvimento de urna nova familia de produtos e servigos, principalmente na 
àrea de supervisào e controle de màquinas de venda (VM 17 ). Este caso de aplicagào 
terà corno foco o desenvolvimento de sistemas de automagào associados à 
evolugào da linha de produtos de VM. 

4.2.2 Sistema de Supervisào de Màquinas de Venda 

A Figura 27 apresenta a estrutura proposta para o sistema para supervisào de 
màquina de vendas, o qual é composto pelos seguintes elementos: 


17 


Do termo em inglès vending machines 
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• Supervisor Central: os dados das VMs sào recebidos pela internet, tratados e 

armazenados. Permite emitir relatórios em tempo reai do status de 
funcionamento de cada VM e relatórios gerenciais de consumo, falhas e 
faturamento. 

• Àrea Fechada: compreende urna regiào fechada com urna rede locai (LAN) 

instalada e com acesso à Internet (hotéis, parques, empresas, universidades, 
indùstrias, etc). Possui diversas VM distribuidas e interligadas através de rede 
wireless (WLAN) ou ethernet. 

• VM - Conexào Mobile: VM em locai com acesso à rede de telefonia celular e 

conectada à Internet através de um modem GSM/GPRS/EDGE. 

• Grupo de VM - Conexào Mobile: conjunto de VMs interligadas por urna rede 

locai ethernet e conectadas à Internet através de um modem 
GSM/GPRS/EDGE. 



Figura 27 - Supervisào de màquinas de venda 
O problema de controlar màquinas de venda (VM) espalhadas geograficamente 
afeta os supervisores das màquinas, os repositores de insumos, os técnicos de 
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manutengào, os proprietàrios dos estabelecimentos e os usuàrios das VM’s. Seu 
impacto resulta em: 

• Perda de vendas, decorrente da falta de produtos nas màquinas, 
ineficiència nos roteiros de visitagào às màquinas para reposigào e 
manutengào. 

• Possibilidade de fraudes, roubos e vandalismos, decorrente da 
periodicidade inadequada das visitas para reposigào e manutengào. 

• Indisponibilidade de VM’s para aquisigào de produtos, devido à falha. 

• Indisponibilidade de produtos para aquisigào nas VM’s, devido à falha de 
reposigào de insumos. 

Urna solugào bem sucedida para o sistema de supervisào e controle de 
màquinas de venda proporcionaria os seguintes beneficios: 

• Redugào do indice de falta de produtos nas màquinas devido à reposigào 

incorreta ou atrasada. 

• Melhoria no planejamento dos roteiros de visita às màquinas para reposigào e 

manutengào. 

• Visualizagào centralizada e em tempo reai do estoque e status das màquinas. 

• Visualizagào centralizada de eventuais falhas e defeitos nas màquinas. 

• Alta disponibilidade das VM’s e dos produtos em estoque. 

O sistema deve atender as seguintes necessidades dos envolvidos: 

• Configurar VMs: permite especificar a configuragào de cada VM a ser 

supervisionada (enderego de instalagào, forma de conexào e tipo de produto). 

• Status VM: permite obter os dados de cada VM em tempo reai contendo 

informagòes de status de funcionamento e estoque de produtos. 
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• Relatório Periodo: permite obter o relatório de status de cada VM dentro de um 
periodo especificado. 


4.2.3 Visào da Engenharia de Processos de Negócio (V2) 


A atividade Modelagem Processos de Negócio (A2.1) associada à solugào de 
controle de màquinas de venda teve corno resultado a modelagem preliminar dos 
processos de negócio, contendo as principais fungóes com as suas entradas, 
saidas, controles e mecanismos, representada em IDEF 0 e apresentada na Figura 
28. 



Registro de 
reposigào 


Registro de 
Manutengào 


Relatórios 


Figura 28 - VM: Representagào dos processos de negócio em IDEF 0 
A atividade Especificagào Preliminar da Modelagem de Negócio em UML 2 


(A2.2) neste caso nào foi realizada. 
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A equipe de analistas de negócio formada por dois profissionais realizou a 
atividade de Modelagem Formai dos Requisitos de Negócio em SysML (A2.3), que 
tomou corno base a representagào em IDEF 0 e resultou no modelo de casos de 
usos de negócio representado em SysML. A Figura 29 apresenta o modelo de casos 
de usos de negócio obtido nesta etapa do trabalho. 



controle de màquinas de venda: 

• Venda Insumo: o usuàrio do sistema adquire insumos nas VM's através 
da insergào de pagamento e retirada do produto desejado. O supervisor 
das VM's obtém os resultados das vendas realizadas. 

• Reposigào Insumo: o responsàvel pela reposigào dos insumos acessa 
as diversas VM's repondo os mais variados tipos de produtos oferecidos 
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para venda. O supervisor obtém os resultados quanto a eventuais faltas 
de produtos e quanto ao histórico dos volumes de reposigào para 
planejamento futuro das reposiqòes. 

• Manutenqào: o tècnico de manutengào executa os trabalhos de 
manutengào preventiva e corretiva das VM's. O supervisor acompanha o 
status de funcionamento das VM's e trata o planejamento das 
manutengòes periódicas e roteiros de visitagào dos técnicos. 

• Administragào: o proprietàrio do estabelecimento onde a VM està 
instalada e o supervisor podem obter relatórios de vendas, reposigào, 
manutengào e falhas. 

4.2.4 Visào da Engenharia de Requisitos (VI) 

Para este estudo foi considerado apenas um dos produtos dentro da familia de 
novos produtos em desenvolvimento, o Sistema de Supervisào de Màquinas de 
Venda de Café, onde a venda é realizada através do consumo de créditos 
armazenados em cartòes indutivos. 

As atividades Eliciagào e Anàlise de Requisitos (A1.1) e Especificagào 
Preliminar dos Requisitos em UML 2 (Al .2) do mètodo de gestào de requisitos da 
Figura 12, neste caso, foram realizadas de forma parcial e diretamente em SysML. 
Urna descrigào dos resultados intermediàrios, incluindo também atividades de 
anàlise e especificagào do sistema, està apresentada no Apèndice A. 

O resultado obtido na atividade Modelagem Formai dos Requisitos em SysML 
(Al .3), também da Figura 12, està representado pelo diagrama de requisitos e pelo 
diagrama de casos de uso do sistema. 
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A Figura 30 apresenta o diagrama de requisitos do Sistema de Supervisào de 
Màquinas de Venda de Café, obtido ao final da Modelagem Formai dos Requisitos 
(Al. 3), onde os requisitos nào funcionais estào modelados. 



Figura 30 - Supervisào VM: Diagrama de Requisitos 
A Figura 31 apresenta o diagrama de casos de uso associado ao Sistema de 
Supervisào de Màquinas de Venda de Café. 
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Figura 31 - Supervisào VM: Diagrama de Casos de Usos 
Este sistema ainda està sendo especificado e as atividades associadas à Visào 
da Engenharia de Requisitos (VI) ainda nào foram concluidas, pois o sistema està 
em fase de negociagào de contrato junto ao cliente final do sistema, no caso a 
empresa que possui as màquinas de venda de café a serem automatizadas e 
supervisionadas. 


4.2.5 Visào da Gestào de Requisitos do Sistema (V3) 


Neste caso a atividade de Solicitagào do Sistema (A3.1) da Figura 12 foi 
realizada após as atividades da Visào da Engenharia de Processos de Negócio (V2) 
e definiu o produto a ser desenvolvido visando a atender às necessidades 
especificas de um cliente jà existente, onde as màquinas de venda de café jà 
realizam a operagào de venda através do consumo de créditos armazenados em 
cartòes indutivos, mas nào possuem supervisào automatizada. Foram definidas as 
ferramentas de controle de versào, adotados os modelos e padróes para os 
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documentos associados ao projeto, e no caso do SysML, foi utilizada a ferramenta 
MagicDraw para modelagem em SysML, apenas corno experimentagào para este 
estudo, pois a licenga de utilizagào fornecida pelo fornecedor da ferramenta nào 
permite a utilizagào para fins comerciais. 

Na atividade Sincronizagào Gerencial de Contendo (A3. 2) manteve as 
ferramentas de traballio, o controle de versóes, a padronizagào de documentos e o 
dicionàrio de dados e vocabolàrio utilizados na Visào da Engenharia de Requisitos 
(VI) e na Visào da Engenharia de Processos de Negócio (V2) 

As atividades Consolidagào dos Requisitos Alinhados com Negócio (A3. 3), nào 
possuem resultados a serem apresentados neste estudo e o mesmo ocorre com as 
atividades de Validagào dos Requisitos do Sistema (A3. 4) e Aceitagào dos 
Requisitos do Sistema em SysML (A3. 5), todas pertencentes à Visào da Gestào de 
Requisitos do Sistema (V3) do mètodo proposto na Figura 12. 
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5 DISCUSSÀO 

Considerando o objetivo deste trabalho que é propor um mètodo de gestào que 
auxilie a comunicagào, durante as etapas de definigào dos requisitos de um sistema, 
entre a equipe de engenharia de requisitos e a equipe de engenharia de processos 
de negócio, através de urna maior aderència entre os requisitos do sistema e o 
modelo de negócio da organizagào, este capitulo apresenta e discute alguns tópicos 
associados ao mètodo de gestào de requisitos proposto no capitulo 3, organizado 
pela discussào de cada urna das visèes propostas no mètodo, ou seja, visào da 
engenharia de requisitos, visào da engenharia de processos de negócio e visào da 
gestào dos requisitos do sistema. 

5.1 VISÀO DA ENGENHARIA DE REQUISITOS 

O referencial teòrico apresentado no capitulo 2, Revisào da Literatura, sustenta 
as atividades propostas para està visào através da abordagem do processo 
unificado de desenvolvimento de software (segào 2.3), engenharia de requisitos 
(segào 2.4) e linguagem SysML (segào 2.5). 

A linguagem SysML foi escolhida corno linguagem de modelagem formai 
devido à suas caracteristicas gràficas, facilidade de aprendizado e por ser urna 
extensào da UML, herdando um potencial numero de usuàrios. Este trabalho nào 
tem corno objetivo comparar e avaliar linguagens formais de representagào. 

Especificamente algumas atividades descritas no mètodo proposto no capitulo 
3 foram baseadas em itens especificos do referencial teòrico. Sào elas: 
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• A atividade Eliciagào e Anàlise dos Requisitos (Al .1 ), tratada na segaci 
3.1.1 deste estudo, està fundamentada e baseada no traballio de 
Kotonya & Sommerville (1998). 

• A atividade Especificagào Preliminar dos Requisitos em UML (Al. 2), 
tratada na segào 3.1.2 deste estudo, està baseada no processo 
unificado (Jacobson et al, 1999) (Kruchten, 2000) (Kroll, 2001) 
(Pressman,2006) (IBMRational, 2008) e na utilizagào da linguagem UML 
(Booch et al, 1999) (Gilleanes, 2004). 

• A atividade Modelagem Formai dos Requisitos em SysML (Al. 3), tratada 
na segào 3.1.3 deste estudo, està baseada na caracteristica da 
linguagem SysML de ser urna extensào da UML 2 (OMGSysML, 2006) 
(Balmelli, 2006), nos recursos de interoperabilidade (OMGMOF, 2007) e 
nas caracteristicas formais de SysML apresentadas na segào 2.5.4 e 
pela RFP que originou a linguagem SysML (OMGRFP, 2003). 

A realizagào das atividades propostas para a Visào da Engenharia de 
Requisitos associado com a atuagào gerencial desempenhada pela Visào da Gestào 
dos Requisitos, propicia a antecipagào da documentagào e formalizagào dos 
requisitos do sistema, pois garante urna maior aderència e sincronizagào com os 
processos de negócio e urna conseguente sustentagào para a negociagào junto aos 
stakeholders dos requisitos sistema. 

5.2 VISÀO DA ENGENHARIA DE PROCESSO DE NEGÓCIO 


As atividades associadas à Visào da Engenharia de Processo de Negócio, 
integrante do mètodo para gestào de requisitos descrito no capitulo 3, foram obtidas 
a partir da pesquisa bibliogràfica retratada no capitulo 2, Revisào da Literatura, 
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especificamente na segào 2.2, Engenharia de Processos de Negócio, para as 
atividades Modelagem de Processos de Negócio (segào 3.2.1) e Especificagào 
Preliminar da Modelagem de Negócio em UML (segào 3.2.2), em que o estudo 
realizado por Vicente (2004) foi utilizado corno referència para o desenvolvimento 
destas duas atividades, fornecendo um mètodo para modelagem de processos e 
requisitos de negócio que permite apoiar a especificagào dos requisitos de sistema 
utilizando UML. 

A atividade Modelagem Formai dos Requisitos de Negócio em SysML (A2.3), 
apresentada na segào 3.2.3, està baseada na caracteristica da linguagem SysML de 
ser urna extensào da UML 2 (OMGSysML, 2006) (Balmelli, 2006), nos recursos de 
interoperabilidade (OMGMOF, 2007) e nas caracteristicas formais de SysML 
apresentadas na segào 2.5.4 e pela RFP que originou a linguagem SysML 
(OMGRFP, 2003). 

Existe a possibilidade das atividades A2.1 e A2.2 serem realizadas 
antecipadamente ao tratamento dos requisitos do sistema, podendo ocorrer até 
mesmo que a modelagem de negócio nào seja realizada. Neste caso, o mètodo de 
gestào de requisitos descrito no capitulo 3, prevè que urna equipe de trabalho seja 
alocada para a realizagào das atividades A2.1 e A2.2, ocasionando um possivel 
aumento dos custos das fases iniciais do projeto. 

5.3 GESTÀO DOS REQUISITOS DO SISTEMA 

As atividades associadas à Visào da Gestào dos Requisitos do Sistema, 
integrante do mètodo para gestào de requisitos descrito no capitulo 3, foram obtidas 
a partir da pesquisa bibliogràfica retratada no capitulo 2, Revisào da Literatura, 
especificamente na segào 2.3, Processo unificado, e na segào 2.4.5, Gerenciamento 
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de requisitos. A experiència pràtica do autor deste estudo no desenvolvimento de 
sistemas de informagào e de automagào, atuando desde a implementagào, 
especificagào e gestào de projetos, também foi utilizada para incorporar 
caracteristicas operacionais e necessidades que sào encontradas em projetos reais. 

Leffingwell & Widrig (2000) propóem um processo para gerenciamento da 
engenharia de requisitos baseado na formagào adequada das equipes de 
desenvolvimento, processo adotado neste trabalho através da separagào explicita, 
mas gerenciada, entre os engenheiros de requisitos e os analistas de negócio, 
atuando respectivamente na Visào da Engenharia de Requisitos e na Visào da 
Engenharia de Processos de Negócio, permitindo que as duas equipes trabalhem de 
forma independente, mas sincronizadas pela equipe de gestào. 

A atividade de consolidagào dos requisitos do sistema alinhados com os 
processos de negócio, descrita na segào 3.3.3, utiliza os recursos oferecidos pelas 
ferramentas CASE de modelagem SysML para verificagào de diferengas sintàticas 
entre dois modelos para tratar as eventuais inconsistèncias existentes entre o 
modelo em SysML obtido corno resultado da Visào da Engenharia de Requisitos e o 
modelo obtido na Visào da Engenharia de Processos de Negócio, para que de forma 
iterativa as inconsistència possam ser tratadas e um modelo de requisitos do 
sistema em SysML, aderente aos processos de negócio possa ser obtido através do 
recurso de fusào de modelos, também oferecido pelas ferramentas CASE de 
modelagem SysML. 

Cabe ressaltar que a atividade de consolidagào dos requisitos do sistema, 
alinhada com os processos de negócio, necessita ser aplicada a casos reais, pois 
este estudo apresenta apenas urna experiència, descrita no capitulo 4, cujo objetivo 
foi explicitar o mètodo proposto e nào demonstrar os artefatos obtidos. 
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As atividades de validagào e aceitagào dos requisitos do sistema em SysML, 
que estào sendo descritas, respectivamente, nas segèes 3.3.4 e 3.3.5, estào 
fundamentadas e baseadas no trabalho de Kotonya & Sommerville (1998). 

Estima-se um maior retorno de investimento, com a utilizagào do mètodo de 
gestào proposto no capitulo 3, quanto maior e mais complexo for o projeto, devido à 
dificuldade de verificagào manual da aderència entre os requisitos do sistema e os 
processos de negócio. 

A antecipagào da documentagào e formalizagào dos requisitos, a aderència 
aos processos de negócio, a negociagào e aprovagào dos resultados parciais junto 
aos stakeholders, a representagào dos requisitos em urna linguagem formai 
reduzindo eventuais ambiguidades, favorecem que as fases iniciais do projeto 
ganhem urna maior importància estratégica dentro do ciclo de vida do projeto e, 
possivelmente, um incremento nos custos para a realizagào destas fases. Entretanto 
oferecem um menor risco de ocorrència de problemas nas fases seguintes à 
definigào dos requisitos com urna consequente redugào dos custo das fases de 
design, implementagào, teste, impiantalo, produgào e manutengào do sistema, 
lembrando que de acordo com Carr (2000) a corregào de problemas de requisitos 
realizados na fase de produgào do sistema produgào pode custar 500 vezes mais do 
que se fossem corrigidos na fase de requisitos. 
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6 CONCLUSÒES E TRABALHOS FUTUROS 

O objetivo deste trabalho, propor um mètodo de gestào que auxilie a 
comunicagào, durante as etapas de definigào dos requisitos de um sistema, entre a 
equipe de engenharia de requisitos e a equipe de engenharia de processos de 
negócio, através de urna maior aderència entre os requisitos do sistema e o modelo 
de negócio da organizagào, foi alcangado através da revisào literària realizada, do 
mètodo de gestào de requisitos proposto no capitulo 3, da adogào de SysML corno 
linguagem formai de modelagem. 

A partir do mètodo de gestào de requisitos proposto no capitulo 3 e dos casos 
apresentados corno ilustragào e descritos no capitulo 4, conclui-se que a 
comunicagào entre as equipes serà mais efetiva e produtiva, pois o mètodo procura 
evoluir gradativamente, e de forma gerenciada, o grau de aderència, quanto aos 
requisitos do sistema, entre a visào da engenharia de requisitos e a visào da 
engenharia de processos de negócio, chegando, nas ùltimas etapas do mètodo, a 
urna representagào ùnica dos requisitos na linguagem formai SysML. 

A comunicagào com os stakeholders serà mais efetiva e produtiva, podendo 
resultar em um processo de aceitagào e validagào dos requisitos mais eficiente, 
convergente e, possivelmente, com tempos de aceitagào final mais curtos, pois o 
mètodo proposto oferece urna maior aderència dos requisitos do sistema com os 
processos de negócio da organizagào, estabelece a realizagào de validagòes 
intermediàrias dos resultados parciais obtidos e utiliza linguagem formai para a 
modelagem dos requisitos permitindo grande redugào das ambiguidades no 
entendimento e interpretagào semàntica do modelo de requisitos. 
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A utilizataci da linguagem formai SysML para modelagem dos requisitos poderà 
também otimizar o traballio a ser realizado pelas equipes envolvidas com as demais 
etapas do ciclo de vida do desenvolvimento do sistema, corno design, 
implementagào, teste e impiantalo, pois oferece corno insumo para estas etapas 
urna modelagem dos requisitos com urna possivel redugào no grau de ambiguidades 
e necessidade de intervengo tanto dos engenheiros de requisitos corno dos 
analistas de negócio. 

A principal limitagào deste trabalho é o fato de o mètodo proposto no capitulo 3 
nào ter sido aplicado a um projeto em sua totalidade. A aplicagào do mètodo 
proposto a casos passados limita a verificagào do impacto sobre as equipes de 
trabalho e sobre o andamento do projeto. Urna nova pesquisa de campo mais 
profunda e detalhada, envolvendo diversos estudos de caso, associados à aplicagào 
reai e completa do mètodo proposto no capitulo 3, poderà oferecer diversos 
resultados, corno: 

• A verificagào e medigào das melhorias obtidas quanto à comunicagào 
entre a equipe de requisitos e a equipe de modelagem de processos, 
durante as atividades de especificagào dos requisitos do sistema. 

• A verificagào e medigào das melhorias obtidas quanto ao tempo de 
validagào e aceitagào dos requisitos do sistema pelos stakeholders. 

• Evolugào e comprovagào das atividades do mètodo proposto no capitulo 
3, associadas à visào da gestào dos requisitos, principalmente quanto à 
consolidagào dos requisitos do sistema alinhados com os processos de 
negócio. 

As conclusèes obtidas e a limitagào indicada para este trabalho sugerem a 
realizagào de novos trabalhos e estudos, tais corno: 
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• Desenvolver técnicas de consolidagào e sincronizagào dos requisitos do 
sistema alinhados aos processos de negócio, utilizando ferramentas 
automatizadas baseadas em linguagens formais de modelagem. 

• Desenvolver pesquisa visando à verificagào da efetividade do mètodo 
proposto em casos reais, através da medigào e verificagào dos resultados 
obtidos. 

• Desenvolver pesquisa visando estender a utilizagào de linguagem formai para 
a etapa de anàlise dos requisitos. 
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APÈNDICE A - Supervisào VM: Especificagào em SysML 

Este apèndice apresenta a especificagào preliminar em SysML do sistema de 
controle e supervisào de màquinas de vendas utilizado corno elemento de apoio 
para o processo de eliciagào dos requisitos do sistema. 

Na especificagào de um sistema a primeira tarefa é decidir o que pertence ao 
sistema e o que nào pertence. Para este firn, utiliza-se o diagrama informai de 
contexto do sistema, apresentado na Figura 32, onde o dominio e as fronteiras do 
sistema sào representados. Neste caso, as operadoras de servigo celular, 
provedoras de acesso à Internet e os equipamentos de màquina de venda 
propriamente ditos, sào considerados externos, pois o sistema trata a supervisào 
dos equipamentos e nào o seu funcionamento e operagào. 
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Figura 32 - Dominio e as fronteiras do sistema 

A Figura 33 apresenta o diagrama de requisitos do sistema de supervisào de 


màquinas de venda, indicando dependèncias entre requisitos e seus racionais. 
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req [Package] VM&4iervis&o{ Esfieatlc-^lo VM j 



Figura 33 - Diagrama de Requisitos 

A Figura 34 apresenta o diagrama de casos de uso contendo as relagòes e 
dependèncias entre os casos de uso e os atores do sistema. 
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podemos observar a estrutura e a representagào das agòes. 
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««adorOiagrain» 

«useCaseModePtagram» 

interaction Sequence Oiagram TratamertoPrNumber[ frftj TratamentoPinNumber 



Figura 35 - Diagrama de Sequència em SysML 
O diagrama de màquina de estado da Figura 36 representa os estados e 
transigòes do caso de uso Acompanhamento Status. 
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state machine State Machine Diagram Acompanhamento Status[ 'p' Acompanhamento Status 



Figura 36 - Diagrama de Màquina de Estado 

O diagrama de paràmetro (Figura 37) representa as restrigòes impostas ao 
tratamento do pagamento, podendo definir desempenho, confiabilidade e 
propriedades fisicas. 


par [Block] TrataPagamentoPinNumber[ Tratamento Pagamento PinNumber )l 
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Figura 37 - Diagrama de Paràmetro 
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O diagrama de pacotes do modelo (Figura 38) mostra a estrutura utilizada para 
avaliar o problema, com os relacionamentos entre os pacotes e as visòes. 


pkg (Pailtage] Domino de MosHcf vM; rfrU! l» aVto cfc? o |l 


dD r — 1 


— 1 


VMCasoslKo 

¥ 

VMCnmportamentn 

J 

VM Fstnitura 


VMSufinrvisao 

* 


VMAnalisp 

T" 


I 


««Import»» 

r i 




/ 

/ / 


VMVisoes 


•<vlew>* p- N , 

V'tsaoOperarioital 


Ponto <J* Visi* 


«conformi 


/ 

/ 

/ / 


VisaoDesenipenho 


n 

«*<conrottti» 


' ^«vie<vficiri >3 

Ponto d» Vi vi j 
Desemponho 


Figura 38 - Estrutura de Pacotes do Modelo 

O diagrama de dominio hieràrquico define formalmente o contexto e as 
fronteiras do sistema (Figura 39). 


bdd [Package] VMEsfrutura[ Supervisao Dominio Herarquco j| 



Figura 39 - Dominio Hieràrquico 
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A estrutura hieràrquica do sistema define os blocos que compòem o sistema e 
os sub-sistemas (Figura 40). 


bdd [Package] VMEstrutura[ SupervlsaoHierarquico~jr 



Figura 40 - Estrutura Hieràrquica do Sistema 

O diagrama de pacotes é utilizado na Figura 41 para definir a visào de 
desempenho associada à aquisigào de insumos pelo usuàrio do sistema nas 
màquinas de venda. 
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Figura 41 - Visào de desempenho 


